Angel Sanchez Güeche
Oct 6, 2026
Índex de continguts
- Una migració no és copiar una base de dades
- Definiu l'abast abans de tocar cap registre
- Migrar dades entre sistemes empresarials requereix un mapa
- Netejar dades no és una fase secundària
- Escolliu una arquitectura que encaixi amb l'operativa
- Proveu el procés amb dades reals, no amb supòsits
- Planifiqueu el canvi de sistema com una operació controlada
- La seguretat i la governança continuen després de la migració
Una migració no és copiar una base de dades
El dia que un ERP nou entra en funcionament, una botiga online canvia de plataforma o el CRM substitueix fulls de càlcul dispersos, el risc no és només tècnic. És operatiu: factures que no quadren, clients duplicats, estoc incorrecte, comandes perdudes o equips que deixen de confiar en el sistema nou. Per això, migrar dades entre sistemes empresarials s'ha de tractar com un projecte de negoci amb implicacions tècniques, no com una simple tasca d'importació.
Per a una pime en creixement, les dades acostumen a estar repartides entre un programa de facturació, un CRM, una eina d'email màrqueting, una botiga online, documents interns i, sovint, diversos fulls de càlcul. El nou sistema pot ser millor, però només aportarà valor si rep informació fiable, ben estructurada i útil per als processos reals de l'empresa.
La pregunta correcta no és «com passem les dades?». És «quines dades necessitem perquè l'operativa, les vendes i l'atenció al client continuïn funcionant millor des del primer dia?».
Definiu l'abast abans de tocar cap registre
El primer error és voler migrar-ho tot. Els sistemes antics acumulen camps obsolets, registres repetits, contactes sense activitat, productes descatalogats i processos que ja ningú no segueix. Traslladar aquest soroll al sistema nou encareix el projecte i deteriora la qualitat des de l'inici.
Cal començar per inventariar les fonts de dades i classificar la informació segons el seu valor operatiu. Habitualment, els blocs prioritaris són clients, contactes, proveïdors, productes, tarifes, comandes, factures, inventari, consentiments de comunicació i historial de servei. Ara bé, la prioritat varia. Un distribuïdor pot necessitar anys d'històric de vendes per mantenir condicions comercials; una empresa de serveis pot resoldre-ho amb contractes actius, factures pendents i converses comercials recents.
També s'ha de decidir què queda fora. No sempre convé traslladar documents antics, oportunitats comercials tancades fa vuit anys o camps creats per a una campanya puntual. Aquesta decisió ha de tenir propietari: direcció comercial, finances, operacions o atenció al client, segons el tipus de dada. L'equip tècnic pot implementar les regles, però no hauria d'inventar-les.
Migrar dades entre sistemes empresarials requereix un mapa
Un bon mapa de dades defineix com es transforma cada element entre l'origen i el destí. No n'hi ha prou amb associar una columna de «nom» amb una altra de «nom». Cal establir significat, format, obligacions, valors permesos i relacions amb altres registres.
Penseu en un client que existeix tres vegades: com a contacte del CRM, com a comprador de la botiga i com a deutor al sistema comptable. Si cada aplicació el representa de manera diferent, importar els fitxers sense una regla d'identificació generarà duplicitats. El resultat és una visió comercial incompleta, comunicacions repetides i informes poc fiables.
Per evitar-ho, convé definir un identificador estable. Pot ser un codi intern, el NRT o NIF quan sigui pertinent, un correu electrònic validat o una combinació de camps. La millor opció depèn del model de negoci i de les obligacions de privacitat. El correu electrònic, per exemple, pot ser útil per a consumidors, però és insuficient per identificar empreses amb diversos contactes.
El mapa també ha d'explicar les transformacions. Una data pot arribar en diversos formats; un import pot contenir impostos o no; un estat de comanda antic pot no existir al nou ERP. En aquests casos, cal documentar l'equivalència o decidir si s'arxiva la dada sense portar-la a l'operativa activa. Les decisions implícites són les que després es converteixen en incidències.
Netejar dades no és una fase secundària
La migració exposa problemes que ja existien. Adreces sense país, telèfons en formats incompatibles, productes sense referència, camps obligatoris buits o clients duplicats no apareixen perquè el sistema nou sigui deficient. Ja eren al negoci, però els sistemes antics permetien conviure-hi.
La neteja ha de combinar regles automàtiques amb revisió humana. Es poden normalitzar codis postals, unificar formats de telèfon, eliminar espais sobrants i detectar coincidències evidents. Però determinar si dues empreses amb noms similars són realment la mateixa, o si una tarifa històrica encara té vigència, requereix coneixement de negoci.
Aquest és un punt on cal ser pragmàtic. Intentar assolir una base de dades perfecta pot bloquejar el projecte. L'objectiu és tenir dades prou correctes per operar amb seguretat i establir un pla per corregir la resta. La diferència és crítica: una migració no ha de ser una auditoria infinita, però tampoc una excusa per importar errors coneguts.
Escolliu una arquitectura que encaixi amb l'operativa
No totes les integracions necessiten el mateix nivell de complexitat. Per a algunes empreses, una exportació controlada, una transformació en fitxer i una importació única són suficients. Per a d'altres, caldrà una integració per API, sincronització programada o una capa intermèdia que coordini diversos sistemes.
La decisió depèn de la freqüència de canvi, el volum de dades i el cost d'un error. Si el CRM i l'eina de facturació han de compartir informació cada dia, una càrrega manual mensual és una font segura de fricció. En canvi, construir una integració en temps real per a un catàleg que només canvia dues vegades l'any pot ser una despesa difícil de justificar.
També cal designar el sistema mestre per a cada tipus de dada. El CRM pot ser la font de veritat dels contactes comercials; l'ERP, de factures i estoc; la plataforma d'ecommerce, de comandes digitals. Quan dos sistemes poden editar el mateix camp sense una regla de prioritat, el conflicte és inevitable.
Proveu el procés amb dades reals, no amb supòsits
Una migració fiable es construeix amb proves repetides. Primer s'executa una migració pilot amb una mostra representativa: clients actius i inactius, comandes amb descompte, factures rectificatives, productes amb variants, casos amb dades incompletes i excepcions conegudes. Si només es validen registres senzills, la prova no demostra res.
Després s'han de comparar resultats amb criteris clars. El recompte de registres és necessari, però no suficient. També cal revisar imports totals, relacions entre entitats, permisos d'accés, estats, camps obligatoris i informes crítics. Si el sistema nou mostra 10.000 comandes però la suma de facturació no coincideix, la migració no està validada.
La validació ha d'incloure les persones que utilitzaran el sistema. Finances ha de comprovar saldos i documents. Vendes ha de revisar fitxes de client i oportunitats. Operacions ha de confirmar inventari, fluxos de comanda i excepcions. Aquesta participació redueix sorpreses i ajuda a detectar requisits que no apareixen en un document tècnic.
Planifiqueu el canvi de sistema com una operació controlada
El moment de passar a producció necessita un pla de tall concret. S'ha de definir quan es bloquegen canvis al sistema antic, quines dades es tornen a carregar per capturar l'activitat més recent, qui valida els resultats i en quin punt es decideix continuar o tornar enrere.
En projectes amb més risc, és útil treballar amb una càrrega inicial i una càrrega delta final. La primera trasllada la major part de l'històric amb antelació. La segona incorpora els canvis produïts durant les darreres hores o dies abans del llançament. Això redueix la finestra d'aturada, però exigeix control sobre què ha canviat i com s'eviten duplicats.
També cal preparar un pla de contingència. No significa assumir que el projecte fallarà; significa saber què fer si una validació crítica no passa. Pot implicar conservar el sistema antic en mode de consulta, mantenir processos manuals temporals o ajornar l'activació d'un mòdul no essencial. Improvisar davant d'una incidència és molt més car que acordar les opcions abans.
La seguretat i la governança continuen després de la migració
Les dades empresarials poden incloure informació personal, financera o comercialment sensible. Durant el projecte, cal limitar accessos, xifrar transferències quan correspongui, controlar fitxers temporals i establir terminis per eliminar còpies de treball. Exportar una base de dades a un ordinador local o enviar-la per canals no controlats pot crear un problema de seguretat que el sistema nou no arreglarà.
Un cop finalitzada la migració, la governança és igualment rellevant. Definiu qui pot crear camps nous, modificar valors mestres, fusionar duplicats o canviar integracions. Sense aquestes regles, la qualitat recuperada durant el projecte es degrada ràpidament.
La millor migració no és la que acaba amb una importació sense errors visibles. És la que deixa l'empresa preparada per treballar amb dades més fiables, responsabilitats clares i sistemes que sostenen el creixement en lloc de frenar-lo. Si el nou entorn simplifica decisions i evita feina manual, la migració ja està generant retorn.
