Migració de dades a l'ERP: què netejar i què arxivar

Demani veure el pla d'una implementació d'ERP i la migració de dades apareixerà com una fase — normalment unes poques setmanes, encaixada entre la configuració i les proves, dimensionada com si moure dades fos un exercici mecànic d'exportar i importar. No ho és. La migració és el moment en què cada supòsit adoptat durant el disseny es troba amb l'historial real i sense depurar de com ha operat de veritat el negoci, i és de manera desproporcionadament freqüent el motiu pel qual les implementacions es retarden, per raons ja tractades en l'article d'aquesta sèrie sobre els patrons de fracàs en implementacions de NetSuite.

El pla tracta la migració com una tasca tècnica: extreure, transformar, carregar. La realitat és que la migració és un exercici de presa de decisions disfressat de tasca tècnica — què traslladar, què netejar abans, què arxivar en lloc de migrar i què deixar enrere del tot — i cadascuna d'aquestes decisions té conseqüències sobre el cost, el calendari i com d'utilitzable és realment el nou sistema el primer dia.

Per què això importa

Subestimar la migració té una signatura de fracàs específica i repetible. El perfilatge s'omet o es fa amb presses, l'estat real de les dades es descobreix durant la mateixa fase de migració en lloc d'abans, i aquest descobriment força una renegociació d'abast i calendari en el punt del projecte amb menys marge disponible — perquè el go-live ja s'ha comunicat normalment al negoci i no es pot moure amb facilitat.

El cost d'equivocar-se aquí també s'acumula després del go-live. Les dades migrades sense una depuració adequada arrosseguen els seus problemes al nou sistema, tret que ara són més difícils de corregir, perquè estan incrustats en un sistema del qual tothom ha començat a dependre i es barregen amb transaccions genuïnament noves. Un registre de client duplicat que existia des de fa anys en el sistema antic és una molèstia; el mateix duplicat, acabat de migrar a un sistema en què tothom confia ara com a font de veritat, indueix activament decisions equivocades.

Hi ha també una qüestió d'abast que la migració força com res més en el projecte no ho fa de manera tan directa: no tot el que hi ha en el seu sistema actual mereix existir en el nou. Clients antics inactius, articles descatalogats, transaccions històriques més enllà del que és legalment exigit — migrar-ho tot per defecte, perquè ningú no ha decidit explícitament el contrari, infla el cost, degrada el rendiment i contamina el nou sistema amb material irrellevant des del primer dia.

D'un cop d'ull: les categories de decisió de la migració

Les categories que més sovint es col·lapsen en "migrar-ho tot" per defecte són la segona i la tercera. L'historial transaccional complet és car de migrar i rarament es necessita amb aquest grau de granularitat — un saldo d'obertura, ben determinat, sol servir millor el negoci que anys d'historial granular que ningú no consultarà, i els requisits legals de conservació se satisfan normalment amb un arxiu accessible i no amb presència viva en el nou ERP.

Què funciona i en què cal ser honest

Què funciona:

Perfilar abans de dimensionar, no durant la migració. Estableixi recomptes de registres, taxes de duplicats, grau d'emplenament dels camps obligatoris i integritat referencial el primer mes del projecte, no en la fase de migració. És el pas amb més palanca de tota la migració i és el que més sovint s'omet sota pressió de temps, precisament perquè sembla que pot esperar.

Decidir la conservació per categoria, deliberadament, amb l'aportació de finances i de l'àrea legal. Els requisits legals de conservació a Ibèria difereixen segons el tipus de document i de registre, i "quant temps necessitem conservar això" és una pregunta de compliment, no una pregunta d'IT. Obtingui la resposta per a cada categoria abans de decidir què migrar i què arxivar.

Depurar abans de migrar, mai després. Un duplicat conegut o un registre mal format s'ha de corregir abans de moure's, no migrar-lo amb la intenció de netejar-lo un cop en producció. Un cop en producció, queda barrejat amb activitat nova real i és considerablement més difícil d'aïllar i corregir.

Migrar saldos d'obertura en lloc de l'historial complet de transaccions sempre que el negoci no necessiti consulta a nivell de transacció. Aquesta opció s'utilitza sistemàticament menys del que caldria perquè fa la sensació de perdre alguna cosa, però en la majoria de les empreses mid-market el detall històric de transaccions gairebé no es consulta després dels primers mesos, i un saldo d'obertura ben determinat preserva tot el que el negoci realment necessita.

Un pas definit i provat de rollback i conciliació. Tota migració necessita una manera de demostrar que les dades del nou sistema coincideixen amb les de l'antic, categoria per categoria, abans de donar de baixa el sistema antic. Ometre això és la via per la qual les empreses descobreixen un error de migració mesos després, quan la comparació ja no és senzilla.

En què cal ser honest:

El perfilatge trobarà coses que ningú no vol sentir. Les taxes de duplicats i els problemes de qualitat de les dades que apareixen durant el perfilatge són sovint més alts del que qualsevol espera, i la temptació és tractar la troballa com una exageració en lloc de com un fet. Pressuposti amb honestedat el temps que portarà aquesta correcció, perquè descobrir l'abast real tard és pitjor que descobrir-lo aviat i que la xifra no agradi.

"Potser ho necessitarem" no és un criteri de migració. Gairebé qualsevol cosa podria concebiblement necessitar-se algun dia. La disciplina consisteix a preguntar què es necessitaria concretament, qui ho necessitaria, en quina circumstància, i si un arxiu en lloc d'una migració viva satisfà aquesta necessitat. La majoria dels casos passen aquesta prova com a "arxivar", no com a "migrar".

La depuració porta més temps del que permet el pla, gairebé sempre. No és una crítica a cap equip en particular — és un tret estructural de la feina, perquè la depuració fa emergir judicis de valor (això és un duplicat, o són dues entitats genuïnament diferents amb el mateix nom?) que no es poden automatitzar del tot i que es multipliquen amb el volum de dades.

L'historial migrat ha de quadrar de veritat, i la conciliació és en si mateixa una tasca significativa. Comparar saldos, recomptes i mostres entre el sistema antic i el nou, categoria per categoria, és feina real que cal planificar i dotar de recursos, no una cosa que es doni per feta com a efecte secundari que els scripts de migració s'executin correctament.

El negoci demanarà coses de tornada després del go-live. Algunes dades arxivades o excloses acabaran sent desitjades, normalment per una disputa concreta amb un client o per una petició d'auditoria inusual. Això és gestionable si l'arxiu és genuïnament accessible, i una crisi si "arxivat" va resultar significar "esborrat".

Marc de decisió: dimensionar i executar la migració

Recorri'l en ordre. Aturi's a la primera coincidència.

1. S'han perfilat les dades — recomptes de registres, taxes de duplicats, emplenament, integritat referencial — amb independència del calendari de migració?
Si no, faci-ho ara, el primer mes del projecte, sigui quina sigui la fase en què el pla situa la migració. Aquesta troballa revalora tot el que ve després i és molt més barat tenir-la aviat.

2. S'ha assignat explícitament cada categoria de dades a migrar, resumir, arxivar o descartar — amb l'aportació de finances i de l'àrea legal sobre conservació?
Si no, faci-ho abans que comenci qualsevol feina tècnica de migració. Optar per defecte per "migrar-ho tot" és una decisió per omissió, i normalment és l'equivocada.

3. Els problemes coneguts de qualitat de les dades s'estan netejant abans de la migració, o s'ajornen a un "ja ho arreglarem"?
Si s'ajornen, aturi's i reconsideri-ho. Migrar dades que se saben defectuoses amb la intenció de corregir-les després falla de manera fiable, perquè la correcció es torna més difícil un cop barrejada amb activitat viva i menys urgent un cop passada la pressió immediata del go-live.

4. Hi ha un procés de conciliació definit que compari les dades del sistema antic i del nou abans de donar de baixa el sistema antic?
Si no, construeixi'l ara. No és una assegurança opcional — és l'únic mecanisme que detecta errors de migració quan encara són barats de corregir.

5. S'han documentat les decisions de conservació amb un responsable designat i retiment de comptes, en particular per a tot allò que no es migrarà?
Si no, documenti-ho abans del go-live. "Vam decidir no migrar X" ha de ser traçable fins a una decisió i un motiu, no reconstruït mesos després quan algú pregunti on ha anat a parar alguna cosa.

6. Tot l'anterior completat — el calendari de migració continua sent realista?
Revisi l'estimació amb honestedat a la llum del que ha trobat el perfilatge. Un calendari de migració fixat abans del perfilatge era una conjectura; un fixat després és una estimació, i rarament són la mateixa xifra.

7. Migrat i en producció — la conciliació s'ha completat i aprovat formalment?
No doni de baixa el sistema antic fins que això estigui fet i documentat. El sistema antic és el seu únic punt de referència per detectar un error de migració i, un cop desaparegut, aquest punt de referència desapareix amb ell.

Cost i esforç indicatius

L'esforç de migració escala molt més amb la qualitat de les dades que amb el volum de dades — un conjunt de dades més petit i més brut pot costar fàcilment més de migrar bé que un de més gran i més net. Sol·liciti un pressupost per a un perfilatge i una estimació amb abast definit.

Preguntes freqüents

Quantes dades històriques necessitem migrar realment?
Menys del que assumeix la majoria de les empreses. Els requisits legals de conservació fixen un mínim, però aquest mínim se satisfà normalment amb un arxiu accessible i no amb presència viva en el nou ERP, i la majoria de les consultes operatives no es remunten més d'un o dos anys. Estableixi la necessitat operativa genuïna per separat de la necessitat legal de conservació — normalment apunten a respostes diferents.

Quina és la causa individual més gran de desviació en una migració?
Ometre el perfilatge o fer-lo amb presses. Gairebé totes les desviacions de migració que hem heretat d'un altre partner es remunten al fet que la qualitat de les dades es va descobrir durant la fase de migració en lloc d'abans, moment a partir del qual passa a ser una renegociació de calendari i pressupost en lloc d'una dada d'entrada de la planificació.

Hem de netejar el sistema antic, o netejar durant la migració?
Netegi abans, sempre que sigui possible. Depurar en el sistema antic sol ser més fàcil, perquè l'equip entén les peculiaritats i l'historial d'aquell sistema, i significa que el nou sistema arrenca genuïnament net en lloc d'heretar una promesa de netejar més endavant que competeix amb totes les altres prioritats posteriors al go-live.

Quant temps hem de mantenir accessible el sistema antic després del go-live?
El suficient per completar la conciliació amb confiança i per atendre la primera onada de peticions del tipus "necessitem alguna cosa que no vam migrar" — segons la nostra experiència, un mínim de diversos mesos, i més per a les dades financeres atesos els cicles legals d'auditoria i de reporting. Donar de baixa massa aviat per estalviar cost de llicències és una falsa economia freqüent i lamentable.

Això s'aplica igual a una migració de CRM o de plataforma d'ecommerce, i no només d'ERP?
Els principis són idèntics — perfilar primer, decidir categories deliberadament, netejar abans de moure, conciliar abans de donar de baixa — tot i que els tipus de dades concrets i les regles de conservació difereixin. La disciplina es trasllada amb independència de quin sistema s'estigui migrant.

Tancament — Propers passos

La migració de dades fracassa com a línia d'un pla perquè no és en realitat una tasca tècnica amb una durada previsible — és una sèrie de judicis de valor sobre en què necessita convertir-se realment l'historial del seu negoci, presos sota la pressió concreta d'una data de go-live que s'acosta. Tractar-la com una fase d'execució en lloc de com un projecte de presa de decisions és el motiu més comú perquè es desbordi.

El correctiu està disponible en gairebé qualsevol moment: perfili les dades amb honestedat, per incòmoda que sigui la troballa, i prengui la decisió de migrar, arxivar o descartar de manera deliberada per a cada categoria en lloc de per defecte. Els projectes que fan això el mes u en lloc del mes quatre són els que no renegocien el seu calendari en el pitjor moment possible.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que presta servei a clients mid-market a tota Ibèria. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen la introducció manual de dades entre els equips de vendes i de finances. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació — convertint fluxos de comandes fragmentats en sistemes fiables i amb automonitoratge.

LinkedIn: https://www.linkedin.com/in/brunogd

Fonts

Les URL són a nivell d'editor i s'han de verificar abans de la publicació.

• Oracle NetSuite, documentació de migració de dades i importació CSV — https://docs.oracle.com/en/cloud/saas/netsuite/
• Agencia Tributaria (Espanya), requisits de conservació de registres — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), requisits de conservació de registres — https://info.portaldasfinancas.gov.pt
• DAMA International, Data Management Body of Knowledge (DMBOK) — dimensions de qualitat de les dades — https://www.dama.org
• Experiència d'Atypical Tech en projectes de migració d'ERP mid-market a Ibèria