Un replatforming ecommerce B2B no és un redisseny amb canvi de CMS. És una migració de regles comercials, dades, integracions, comptes i senyals SEO que ja sostenen part del negoci. Tractar-lo com un projecte visual és la manera més ràpida de descobrir en producció que el nou frontend funciona però el client equivocat veu el preu equivocat.
La manera de reduir risc és construir un inventari abans de construir la nova plataforma. Cal saber quins comportaments existeixen, quins sistemes participen i quines dependències no estan documentades. Després es pot decidir què conservar, què simplificar i què eliminar.
Quan té sentit un replatforming
Els senyals habituals són deute tècnic que impedeix evolucionar, integracions fràgils, costos desproporcionats, mala experiència mòbil, impossibilitat de gestionar regles B2B o un stack que ja no suporta seguretat i rendiment. També pot aparèixer després d’una adquisició, expansió internacional o canvi d’ERP/PIM.
La pregunta no és si la plataforma és antiga, sinó si limita objectius comercials i operatius. Un sistema estable que compleix la seva funció pot necessitar modernització gradual, no necessàriament substitució.
1. Inventari de funcionalitats i excepcions
Documenta totes les funcions visibles i les regles ocultes: login, rols, catàlegs per compte, tarifes, descomptes, mínims, impostos, mètodes d’enviament, aprovació, crèdit, pressupostos, comandes recurrents, devolucions, documentació i notificacions.
Marca quines regles són estàndard, quines són acords amb pocs clients i quines són pedaços històrics que ja no haurien d’existir. Migrar cada excepció sense qüestionar-la trasllada deute d’una plataforma a una altra.
2. Mapa de sistemes i fonts de veritat
Un replatforming ecommerce B2B necessita un mapa d’ERP, PIM, CRM, WMS, TMS, identitat, pagaments, analítica i sistemes documentals. Per a cada domini defineix propietari, direcció del flux, freqüència i comportament davant d’error.
No et limitis a APIs documentades. Investiga tasques cron, exportacions CSV, processos manuals i consultes directes que hagin aparegut amb els anys. Moltes migracions fallen per dependències que ningú considerava part de l’arquitectura.
3. Migració de comptes i usuaris
Un compte B2B pot contenir múltiples usuaris, adreces, centres, rols i condicions. Decideix què es migra, com es reconcilien duplicats i com es gestionen contrasenyes. De vegades les credencials no es poden traslladar i cal dissenyar un procés d’activació segur.
Prova comptes representatius: client gran amb diversos centres, distribuïdor internacional, compte amb crèdit bloquejat, comprador amb aprovador i usuari només de documentació. Els casos límit han d’aparèixer abans del cutover.
4. Preus i condicions comercials
El preu és un dels punts més sensibles. Identifica si es calcula a l’ERP, a ecommerce o mitjançant servei específic. Reprodueix casos de tarifes, descomptes, escalats, promocions, monedes i impostos. Comparar resultats entre plataforma antiga i nova amb un conjunt de comptes de prova és més segur que confiar només en especificacions.
5. Catàleg i dades de producte
Defineix quina informació procedeix de PIM, ERP o altres fonts: SKU, nom, atributs, categories, compatibilitats, documents, imatges i traduccions. Replatforming és una oportunitat per millorar taxonomia, però canviar-la sense pla pot afectar URLs, cerca i processos interns.
Conserva identificadors estables quan sigui possible. Si una referència canvia d’ID sense necessitat, les integracions i l’històric es compliquen.
6. Comandes i històric
No sempre cal migrar cada detall d’anys de comandes al nou motor transaccional. Una opció és conservar històric en un servei o base de consulta i migrar només el període necessari. La decisió ha d’equilibrar experiència de client, compliment i complexitat.
L’important és que l’usuari pugui trobar el que necessita i que vendes i suport mantinguin traçabilitat. No confonguis migració física de dades amb accés funcional.
7. SEO: inventari d’URLs abans de dissenyar redirects
Exporta totes les URLs indexables, sitemaps, pàgines principals, enllaços externs i consultes que generen impressions. Classifica cada URL: mantenir, consolidar, redirigir o retirar. Un mapa de redireccions no s’hauria de construir automàticament només per similitud de slug.
Les pàgines de producte i categoria amb demanda han de tenir destí equivalent. Evita cadenes, redireccions a la pàgina d’inici i pèrdua de contingut que explicava aplicacions o especificacions. Revisa canonicals, hreflang, robots, metadades i dades estructurades.
8. Mantenir senyals útils per GEO i motors d’IA
La migració també pot esborrar informació que els models utilitzen per entendre l’empresa: pàgines de solució, definicions, casos, comparatives, dades d’entitat i documentació. Conserva o millora aquesta estructura. Els motors generatius necessiten contingut explícit i enllaçable, no només una interfície més moderna.
Després del llançament monitoritza canvis en indexació, snippets, AI Overviews i consultes informacionals rellevants. SEO i GEO comparteixen la necessitat de fonts accessibles i coherents.
9. Proves funcionals basades en escenaris
No provis només pantalles. Prova escenaris de negoci complets: un distribuïdor inicia sessió, veu el seu catàleg, afegeix un producte amb descompte, tria centre, confirma comanda, ERP la rep i l’estat torna al portal. Un altre usuari sol·licita pressupost, un altre descarrega certificat i un altre intenta una acció que no té permís per executar.
Automatitza casos crítics quan sigui possible i conserva un conjunt de proves de regressió per a futures versions.
10. Proves de càrrega i rendiment
El dia de llançament no hauria de ser la primera vegada que la plataforma rep un catàleg complet o pics d’usuaris. Prova cerca, importacions, sincronitzacions i checkout amb volums realistes. Observa TTFB, consultes lentes, cues, memòria i temps d’API.
11. Pla de cutover
Defineix finestres de congelació, sincronització final, DNS, rollback, responsables i criteri de no-go. L’equip ha de saber què passa si una integració crítica falla trenta minuts abans del canvi. Un pla de rollback provat val més que una confiança genèrica que tot anirà bé.
Redueix canvis simultanis. Migrar plataforma, ERP, domini i model de preus el mateix cap de setmana multiplica les variables quan apareix un problema.
12. Observabilitat després del llançament
Durant les primeres setmanes monitoritza errors de login, fallades de sincronització, discrepàncies de preu, comandes rebutjades, cerques sense resultats, 404, conversions i temps de resposta. Crea alertes sobre processos crítics i una rutina diària de revisió.
Compara també amb la línia base. Si baixen tiquets però pugen errors de comanda, el projecte no ha millorat realment l’operació.
Com organitzar el projecte
Divideix el treball en discovery, disseny d’arquitectura, migració de dades, construcció, proves, cutover i estabilització. Cada fase ha de produir artefactes que la següent pugui utilitzar: inventari, contractes de dades, mapa de redireccions, casos de prova, runbook i tauler d’observabilitat.
El responsable de negoci ha de participar en decisions sobre excepcions i prioritats. Si totes les preguntes es resolen entre desenvolupament i IT, la nova plataforma pot ser tècnicament neta però comercialment incorrecta.
Preguntes freqüents
Cal migrar tot l’històric?
No sempre. L’important és mantenir accés i compliment. Part de l’històric pot quedar en un sistema de consulta si no necessita viure en el nou motor.
Quant temps s’ha de mantenir el seguiment SEO?
Com a mínim diverses setmanes amb seguiment diari inicial i després revisió periòdica durant mesos. Els efectes de rastreig i indexació no apareixen tots el dia del llançament.
Es pot fer replatforming per fases?
Sí. En molts entorns B2B redueix risc desacoblar frontend, catàleg, compte o checkout i migrar-los progressivament, sempre que l’arquitectura permeti convivència temporal.
Governança de contingut durant la migració
Replatforming acostuma a durar mesos, de manera que la plataforma antiga continua rebent canvis. Defineix una política de congelació progressiva: quin contingut es pot continuar editant, quins canvis s’han de replicar en tots dos entorns i des de quina data la nova plataforma es converteix en font principal. Sense aquesta regla, equips de màrqueting i producte poden estar actualitzant dues versions divergents de la mateixa fitxa.
Documenta també responsables d’aprovació. Una migració no hauria de publicar automàticament informació desactualitzada només perquè estava tècnicament disponible a la base antiga.
Analítica i consentiment: migrar sense perdre comparabilitat
Configura mesurament abans del cutover i valida esdeveniments a staging. Mantén noms comparables per a cerques, login, RFQ, add-to-cart, checkout i descàrrega de documents. Si canvies tota la taxonomia d’esdeveniments el mateix dia que la plataforma, serà difícil saber si una variació prové del negoci o del mesurament.
Revisa consentiment, tags, server-side events i exclusions internes. El llançament ha de tenir un tauler mínim que permeti detectar caiguda de conversions o anomalies sense esperar l’informe mensual.
Pla de comunicació a clients
Els comptes B2B necessiten saber què canvia, quan i què han de fer. Si hi haurà restabliment de contrasenya, nova URL, canvis en comanda o períodes de manteniment, comunica-ho per segments i amb antelació. Inclou suport reforçat durant els primers dies. Una migració tècnicament perfecta es pot percebre com dolenta si el client descobreix els canvis per sorpresa.
Checklist de preparació abans d’aprovar el go-live
Una setmana abans del canvi, revisa un checklist conjunt de negoci i tecnologia: comptes pilot verificats, preus comparats, comandes de prova reconciliades, redireccions carregades, analítica validada, emails transaccionals, backups, rollback i responsables de guàrdia. Cada punt ha de tenir evidència, no només un “fet” en una fulla.
Defineix també quines incidències permeten llançar i quines obliguen a ajornar. Prendre aquest criteri en fred evita que la pressió de calendari converteixi un error crític en una decisió emocional la nit del cutover.