Migrare a PrestaShop o trasferire un negozio esistente su un nuovo server

Cosa faremmo

Sceglieremmo il percorso in funzione del negozio che gestisci già: configurazione, qualità dei dati, moduli o app di origine, tema, integrazioni, mercati e team responsabile delle operazioni quotidiane. Un cambio di piattaforma sostituisce i workflow aziendali; un trasferimento di server senza cambio di versione dovrebbe preservarli. Concorda quale lavoro stai acquistando prima di scegliere uno strumento o accettare un preventivo.

Per una migrazione di piattaforma, costruiremmo un negozio PrestaShop di staging pulito e protetto e verificheremmo le mappature con dati rappresentativi prima dell'importazione completa. Per un trasferimento di server, proveremmo una copia coerente dell'installazione esistente sull'hosting di destinazione, mantenendo invariata la versione dell'applicazione dove possibile. In entrambi i casi, pianifica il passaggio finale, identifica il sistema autorizzato ad accettare scritture e concorda una procedura di ripristino che conservi gli ordini ricevuti dopo il lancio.

Se la scelta dell'hosting richiede una valutazione specialistica, il PrestaShop Hosting & Infrastructure Audit valuta se trasferirsi o migliorare l'hosting attuale; esecuzione della migrazione e modifiche alla configurazione non rientrano nel suo ambito.

Decidi cosa deve ottenere il trasferimento

Elenca il limite effettivo che vuoi risolvere: struttura del catalogo, personalizzazione del checkout, contenuti multilingue, controllo dell'hosting o delle integrazioni. Confronta il costo operativo totale della permanenza con quello del trasferimento su due o tre anni, usando contratti e carico di lavoro reali. Includi hosting, manutenzione, backup, sicurezza, supporto degli sviluppatori, estensioni, abbonamenti, commissioni di pagamento, lavoro di migrazione e formazione del personale.

PrestaShop su hosting gestito da te ti dà il controllo sul codice e sull'infrastruttura e la responsabilità di gestirli. Non garantisce una spesa inferiore o costi fissi al crescere dell'utilizzo. Le licenze dei moduli possono includere costi ricorrenti di supporto o aggiornamento. Controlla ogni contratto.

I piani standard Shopify offrono già personalizzazioni del marchio e alcune personalizzazioni di checkout/account. La sua tabella delle funzionalità del checkout distingue queste possibilità dalle estensioni delle app riservate a Plus nelle pagine di informazioni, spedizione e pagamento. Definisci con precisione la funzionalità mancante prima di considerare la migrazione come risposta.

Restare può essere sensato quando catalogo, POS, checkout e modalità di assistenza attuali soddisfano le tue esigenze e non hai risorse per gestire un'altra piattaforma. Evita di sostituire per abitudine ogni vecchia app con un nuovo modulo. Mappa prima il requisito aziendale.

Censisci dati, funzionalità e controlli di accettazione

• Catalogo: categorie/collezioni, prodotti padre, varianti, SKU, riferimenti fornitori, GTIN, caratteristiche, descrizioni, immagini, prezzi, regole fiscali, scorte, peso e dimensioni.
• Persone: clienti, ospiti, indirizzi, gruppi, campi aziendali, registrazioni del consenso e requisiti di attivazione degli account.
• Transazioni: righe d'ordine, indirizzi storici, totali di imposte e sconti, valute, riferimenti di pagamento, fatture, note di credito, spedizioni e rimborsi.
• Contenuti: pagine CMS e blog, menu, traduzioni, metadati, canonical, link linguistici e vecchi URL.
• Comportamento: metodi di pagamento, corrieri, visualizzazione delle imposte, sconti, abbonamenti, pacchetti, fedeltà, B2B, marketplace, integrazioni ERP e contabili.

Decidi cosa migrare, cosa ricostruire e cosa lasciare disponibile in un archivio legacy protetto. Conserva gli ID sorgente e una mappa degli ID di destinazione per ogni entità correlata, anche se mantieni deliberatamente alcuni ID. Documenta le esclusioni affinché l'assistenza sappia dove trovare le vecchie informazioni.

Definisci controlli di accettazione misurabili: conteggi delle entità, combinazioni rappresentative, totali per valuta, scorte per posizione/ambito e operazioni di assistenza clienti funzionanti. Controlla relazioni e flussi operativi oltre ai conteggi dei prodotti.

Scegli la versione di destinazione e prova in sicurezza

Crea un'installazione di staging protetta. Scegli una versione PrestaShop 9 mantenuta e supportata da tema, moduli e integrazioni. Usa le versioni PHP e database richieste da quella versione esatta. L'attuale tabella ufficiale di compatibilità distingue 9.0, che raccomanda PHP 8.4, da 9.1, che raccomanda PHP 8.5. Non riutilizzare una ricetta generica di installazione di pacchetti PHP 8.1 in una nuova installazione.

Predisponi le estensioni richieste ed esamina impostazioni PHP, archiviazione, permessi e limiti del server. Non scegliere valori universali arbitrari di memoria o timeout. Verifica gli ambienti di esecuzione web e CLI effettivi.

Blocca l'indicizzazione dello staging e limita l'accesso. Isola email in uscita, pagamenti, attività cron, esportazioni marketplace e scritture ERP affinché una prova non invii notifiche ai clienti né modifichi sistemi live. Conserva backup e prova il ripristino prima dell'esecuzione finale.

Stima i tempi a partire da una prova rappresentativa e da un elenco delle funzionalità da ricostruire. Includi nella stima pulizia dei dati, ricostruzione delle integrazioni e test di accettazione. Registra separatamente i tempi di esportazione, trasformazione, importazione e convalida: il progetto completo e la finestra finale di blocco delle scritture sono stime diverse. Scegli una finestra di lancio in cui i tuoi contatti per assistenza, pagamenti e integrazioni possano rispondere.

Esporta e mappa i dati Shopify

Esporta prodotti, profili cliente e dati ordine disponibili usando gli strumenti o le API Shopify appropriati. Censisci separatamente metafield, registrazioni di proprietà delle app, media, collezioni e contenuti. Un CSV dei prodotti non è un'esportazione completa del negozio. Pianifica separatamente gli articoli del blog Shopify e le relative funzionalità: le pagine CMS del core di PrestaShop non riproducono un blog completo.

Mappa le varianti Shopify sulle combinazioni PrestaShop e decidi come trasformare le collezioni nella gerarchia delle categorie. Conserva i riferimenti prodotto e registra gli ID di origine e destinazione. Ricostruisci esplicitamente il comportamento delle app. Un prodotto può appartenere a più collezioni, quindi decidi separatamente le appartenenze alle categorie e la categoria predefinita. Documenta ogni regola automatica delle collezioni che deve continuare a mantenere tali appartenenze dopo il lancio.

Le normali esportazioni dei clienti non forniscono credenziali di accesso funzionanti trasferibili. Importa profili e indirizzi, poi offri un flusso verificato di attivazione o reimpostazione password. Non spiegarlo come se avessi esportato hash Shopify da convertire semplicemente di formato.

PrestaShop supporta entità core multilingue, ma i campi di un modulo sono multilingue solo se l'implementazione lo supporta. Verifica traduzioni, selezione della valuta, imposte e ogni front office invece di presumere che il supporto linguistico nativo copra ogni sostituzione di app.

Gli ordini storici richiedono un importatore o un flusso di archiviazione scelto. L'importatore CSV nativo PrestaShop non ha un'entità Ordini. Verifica se la soluzione di migrazione crea ordini operativi modificabili, record di consultazione o entrambi.

Esporta prodotti, clienti e ordini HPOS di WooCommerce

Per i prodotti, usa Products > All Products > Export. Abilita l'esportazione dei metadati personalizzati dove necessario ed esamina le colonne meta: risultanti. Questa possibilità è documentata nella guida CSV prodotti di WooCommerce.

Censisci i comportamenti specifici dei plugin come abbonamenti, pacchetti, opzioni aggiuntive dei prodotti e regole di prezzo. I metadati esportati non ricostruiscono di per sé il comportamento. Conserva i metadati SEO del plugin SEO installato, inclusi campi come _yoast_wpseo_title e _yoast_wpseo_metadesc quando presenti.

L'esportatore prodotti non è un esportatore generale di clienti/ordini. Usa un esportatore scelto esplicitamente o le API WooCommerce per queste entità. Con HPOS, i dati d'ordine possono risiedere in tabelle dedicate; non affidarti a una query sul database basata solo sui post.

Converti le variazioni in combinazioni. Elimina o sostituisci shortcode WordPress e markup dei builder nelle descrizioni. Ricostruisci menu, funzionalità del blog e layout del tema. Un tema WordPress non è un tema PrestaShop.

Le colonne immagini di un'esportazione prodotti WooCommerce contengono URL anziché i file delle immagini. Mantieni le immagini di origine raggiungibili durante l'importazione oppure scarica gli originali e predisponi un percorso di trasferimento controllato. Conferma che la destinazione abbia copie proprie utilizzabili, incluse le associazioni alle combinazioni, prima di dismettere l'hosting dei media di origine.

Verifica un prodotto variabile prima dell'importazione completa

Prendi una camicia venduta in più taglie e colori. La variante di origine Taglia M e Colore Blu ha riferimento, scorte e immagine propri. Importa prima la camicia padre, poi collega quella variante come combinazione al padre mappato. Per l'importazione nativa delle combinazioni, calcola l'impatto sul prezzo IVA esclusa come prezzo netto ordinario della variante meno prezzo base netto del prodotto padre; non importare il prezzo completo della variante come impatto. Verifica che selezionando M e Blu compaiano riferimento, immagine, disponibilità e prezzo finale corretti e che la combinazione prevista sia selezionata per impostazione predefinita.

Il conteggio dei prodotti può risultare corretto mentre questo test fallisce: importare ogni variante come prodotto autonomo fa perdere il selettore, mentre associarla al padre sbagliato produce un catalogo plausibile ma errato. Conserva gli identificatori del padre e della variante di origine nella mappatura per risalire da entrambi gli errori alla riga interessata.

Tieni distinti prezzi ordinari, scontati e imposte

Controlla se i prezzi di origine includono le imposte. Mappa consapevolmente i campi netti e lordi. Per esempio, 120 EUR comprensivi di un'unica imposta del 20% corrispondono a 100 EUR prima delle imposte; importare 120 EUR come netto porta il lordo a 144 EUR con quell'aliquota. Le regole fiscali reali possono essere più complesse, quindi prova i carrelli nella destinazione. Registra Prezzi inseriti con imposte in WooCommerce > Impostazioni > Imposte prima di trasformare l'esportazione. Mappa un prezzo in offerta sullo sconto tramite prezzo specifico previsto, con date e condizioni applicabili di cliente o valuta, anziché sostituire per errore il prezzo ordinario. Controlla sia l'offerta visualizzata sia il totale del carrello.

Mappa esplicitamente i concetti Magento o Adobe Commerce

Identifica edizione sorgente ed estensioni. Account aziendali B2B, preventivi e liste di richiesta d'acquisto di Adobe Commerce non vanno attribuiti in blocco al core Magento Open Source. Censisci prezzi specifici per cliente, ricerca e staging dei contenuti e decidi come implementare ciascuno nella destinazione.

La modalità B2B di PrestaShop espone campi degli account aziendali. Prezzi di gruppo, prezzi specifici per cliente e visualizzazione al netto delle imposte richiedono configurazioni proprie. Abilitare la modalità non li imposta tutti.

Ricostruisci le integrazioni sulle risorse e operazioni effettivamente disponibili. Webservice legacy, Admin API di PrestaShop 9 ed endpoint dei moduli hanno copertura e autenticazione diverse. Non presumere che un'integrazione REST o GraphQL sorgente si trasferisca invariata.

Le normali modifiche ai prezzi dei prodotti Magento sono operazioni amministrative. La complessità di distribuzione del codice non è un motivo fattuale per affermare che ogni cambio di prezzo richieda Composer o una pipeline di distribuzione.

Per esempio, la Taglia selezionabile di un capo appartiene al modello delle combinazioni, mentre una descrizione fissa del Tessuto può diventare una caratteristica. Confronta un prodotto configurabile mappato con gli SKU figli di origine, poi effettua un ordine di prova come cliente aziendale. Scorte corrette delle varianti non dimostrano che il prezzo negoziato o i permessi dell'account aziendale siano stati conservati.

Scegli come trasferire i dati

Seleziona un metodo a partire da una mappatura scritta e un'esportazione campione. La dimostrazione di un connettore con prodotti semplici non dimostra il supporto per abbonamenti, campi aziendali personalizzati o storico ordini. Richiedi riscontri sui tuoi dati rappresentativi.

Se ti serve aiuto per una funzione mancante, il PrestaShop Module Selection & Fit Assessment valuta i percorsi per soddisfare quel requisito, mentre il PrestaShop Custom Module Development Service definisce e quota separatamente il lavoro su moduli o integrazioni su misura.

Importa nell'ordine delle dipendenze e verifica le relazioni

1. Crea struttura dei negozi, lingue, valute, regole fiscali, gruppi cliente e gerarchia delle categorie.
2. Importa i prodotti principali con chiavi stabili e categorie mappate. Convalida i prezzi prima di aggiungere le immagini.
3. Importa le combinazioni usando l'ID del prodotto principale o il riferimento prodotto con corrispondenza per riferimento abilitata. Imposta in questo passaggio la combinazione predefinita prevista.
4. Trasferisci le immagini e verifica associazioni e dimensioni generate.
5. Importa clienti e indirizzi, conservando relazioni e informazioni sul consenso.
6. Importa gli ordini storici solo tramite il meccanismo supportato scelto. Disattiva effetti collaterali indesiderati su email, scorte o integrazioni.
7. Ricostruisci gli indici applicabili, confronta conteggi e totali ed esamina i record sia nel front office sia nel back office.

Gli identificatori dell'importazione nativa variano per entità. Non presumere di poter scegliere qualsiasi colonna come chiave universale di corrispondenza. Consulta la guida all'importazione dei prodotti per CSV e gestione degli errori parziali.

Prova esplicitamente valute, valori fiscali storici e rimborsi. Ricalcolare vecchi ordini usando il catalogo o la configurazione fiscale di oggi può modificare le registrazioni che volevi conservare.

Conserva un log di importazione che colleghi le righe fallite agli ID di origine e al motivo dell'errore. Prova un nuovo tentativo corretto anziché presumere che un lotto scaduto per timeout non abbia importato nulla. Per le immagini, distingui un URL di origine irraggiungibile o un ridimensionamento fallito da una riga prodotto fallita prima di modificare max_execution_time o riavviare l'intero job.

Conserva l'accesso agli account e una cronologia ordini utilizzabile

Per migrazioni da Shopify, WooCommerce e Magento, prevedi un flusso di reimpostazione o attivazione salvo aver verificato un ponte di accesso compatibile. In PrestaShop 1.7.8 e 9.1, il formato CSV clienti nativo richiede un campo Password e ne calcola l'hash. Fornire un hash sorgente esistente come valore non conserva la password di accesso originale. Usa uno strumento di migrazione con una politica esplicita sulle credenziali; per nuovi account basati su password, usa un segreto iniziale non indovinabile e un flusso verificato di reimpostazione o attivazione senza inviarlo via email.

Un ponte progettato separatamente può verificare un vecchio hash supportato e ricalcolare l'hash della password a un accesso riuscito. Richiede accesso alle credenziali sorgente, un modello di sicurezza definito e test. Non prometterlo per una piattaforma le cui esportazioni non forniscono quel materiale.

Verifica link di reimpostazione, lingua, consegna e corrispondenza degli account prima di invitare i clienti. Evita di inviare password temporanee via email. Spiega chiaramente il cambiamento e mantieni disponibile un percorso di recupero dell'account.

Per gli ordini storici, controlla le capacità effettive dell'importatore scelto: il personale può vedere le righe, emettere documenti, aggiornare informazioni di spedizione o gestire resi? Un rimborso tramite il gestore dei pagamenti richiede riferimenti adeguati alla transazione originale, accesso all'account e supporto dell'integrazione. Mantieni il flusso del vecchio fornitore o un back office legacy protetto dove necessario.

Conserva URL, metadati e reperibilità

1. Combina scansione del sito sorgente, sitemap, esportazioni URL della piattaforma, analisi, backlink e log del server disponibili. Le esportazioni del rendimento Search Console sono utili ma non costituiscono un inventario URL completo.
2. Mappa i vecchi URL di prodotti, categorie, CMS, blog, lingue e immagini a destinazioni pertinenti. Mantieni reindirizzamenti diretti e permanenti, normalmente HTTP 301 per un trasferimento permanente.
3. Conserva inizialmente titoli, descrizioni e contenuti utili. Rimuovi consapevolmente i contenuti obsoleti ed evita di inviare ogni pagina rimossa alla homepage.
4. Controlla URL canonici, link linguistici, link interni, direttive robots e controlli di accesso dello staging.
5. Genera la nuova sitemap e inviala dopo il lancio. Usa il report Indicizzazione delle pagine di Search Console e Controllo URL; usa Impostazioni > Statistiche di scansione per la diagnosi di scansione/server.

Percorsi sorgente tipici come /products/blue-widget o /product/blue-widget/ possono diventare un URL prodotto PrestaShop configurato. Genera prima la destinazione effettiva; non presumere che ogni negozio usi gli stessi ID, prefissi di lingua o suffisso .html.

Implementa le mappature in blocco con regole server testate, un gestore di reindirizzamenti adatto o uno script di migrazione. I reindirizzamenti dei singoli prodotti di PrestaShop non sono uno strumento completo di migrazione in blocco. Per la gestione continuativa di indirizzi e reindirizzamenti, Smart SEO Friendly URL Manager gestisce schemi delle pagine e vecchi indirizzi; convalida in staging le mappature richieste dalla migrazione prima di affidarle al modulo. Il posizionamento può cambiare anche per contenuti, disponibilità, velocità, canonical e reindicizzazione; una mappa dei reindirizzamenti non può garantire traffico invariato.

Per un prodotto mappato, prova un vecchio link proveniente da una campagna o da un risultato di ricerca usando hostname e lingua previsti. Registra la risposta di reindirizzamento e seguila fino alla pagina finale: un reindirizzamento a un prodotto mancante, a un altro reindirizzamento o alla lingua sbagliata resta un errore. Controlla il canonical finale e che il prodotto sia acquistabile, poi ripeti la verifica dopo il passaggio pubblico. La guida a URL e reindirizzamenti tratta gli altri controlli sugli URL.

Sposta un'installazione PrestaShop esistente su un altro server

Il trasferimento su un altro server dello stesso negozio normalmente sposta file e un database coerente anziché ricostruire clienti e prodotti tramite CSV. Se possibile, separa un aggiornamento di versione principale dal cambio di host per poterli verificare singolarmente.

1. Censisci domini, URL multinegozio, origini CDN, attività cron, worker, impostazioni email, file personalizzati, regole del server web e callback esterni.
2. Prepara ambiente di esecuzione e database di destinazione. Conserva charset/collation del database e comportamento dello schema richiesto. Assegna all'applicazione credenziali database appropriate.
3. Copia l'installazione, inclusi immagini, caricamenti, temi, moduli e file nascosti/di configurazione necessari. Tieni gli archivi fuori dalla radice pubblica dei documenti.
4. Esporta e ripristina un database coerente. Per tabelle InnoDB transazionali, può aiutare un dump in singola transazione; considera le tabelle non transazionali ed evita modifiche allo schema durante il dump.
5. Aggiorna le credenziali di connessione della destinazione in app/config/parameters.php per PrestaShop moderno. Conserva i segreti crittografici dell'applicazione. La versione legacy 1.6 usa file di configurazione diversi.
6. Applica proprietà e permessi adatti all'host. Non rendere alla cieca ogni file scrivibile dal processo web e non copiare comandi universali sui permessi.

# Illustrative file transfer; replace paths and remote account.
rsync -avz --progress -e ssh /srv/shop/ deploy@new-host:/srv/shop/

# Example database export for an appropriate InnoDB installation.
mysqldump -u ps_backup -p --single-transaction --routines --triggers shop > shop.sql

# Restore into the prepared target database.
mysql -u ps_restore -p shop < shop.sql

Questi esempi richiedono permessi dell'account e un piano di backup specifico dell'installazione. Proteggi il dump ed elimina le copie temporanee dopo una prova di ripristino riuscita. Non ripristinare un dump sul database live sbagliato.

Se dominio pubblico e percorso restano uguali, conserva quegli URL del negozio. Se cambiano, aggiorna i record effettivi degli URL del negozio, inclusi dominio, dominio SSL e URI fisico/virtuale, nel contesto corretto. Gli URL multinegozio moderni sono rappresentati da shop_url; cambiare due nomi di configurazione generici non è un trasferimento multinegozio completo.

Verifica un trasferimento di server senza cambio di dominio

Supponi che il negozio mantenga dominio pubblico e versione PrestaShop ma passi a un altro hosting. Una homepage funzionante sul nuovo server è solo un controllo iniziale. Effettua un ordine di prova supportato dal fornitore tramite il percorso controllato di destinazione e verifica ordine, file caricati, immagini generate, posta in uscita ed elaborazione in background. Controlla percorsi dei file e configurazione specifica dell'hosting oltre al database copiato.

Un fornitore di pagamento può continuare a chiamare il vecchio hosting mentre il tuo browser usa quello nuovo. Associa un riferimento di notifica ai log e alla registrazione ordine di destinazione. Se il callback raggiunge la vecchia installazione, correggi instradamento e controlli delle scritture prima di abilitare le vendite sulla destinazione.

Prepara i certificati e controlla il passaggio finale

Installa i certificati per i nomi host di produzione effettivi prima del lancio. Un certificato emesso per un nome host temporaneo non copre il dominio di produzione. La convalida DNS può essere utile prima che quel dominio punti al nuovo host.

Verifica la destinazione con il suo nome host reale tramite una modifica locale del file hosts o un percorso controllato equivalente. Questo verifica il tuo browser, non il percorso usato dai fornitori di pagamento o da altri chiamanti remoti. Includi test dei callback e accesso dei fornitori nel piano di passaggio.

# Example entry on your test workstation only.
203.0.113.50 example.com www.example.com

1. Riduci i TTL DNS pertinenti abbastanza presto da far scadere il TTL precedente. Esamina record A, AAAA, www, CDN e proxy/origine.
2. Al passaggio finale, interrompi nuovi ordini e altre scritture nel vecchio sistema. La sola modalità manutenzione potrebbe non fermare callback, client API, attività cron o scritture amministrative.
3. Completa il trasferimento finale di database/file o un delta finale verificato per una migrazione di piattaforma. Riconcilia clienti, ordini, scorte, prezzi e caricamenti creati dopo la prova.
4. Instrada il traffico al nuovo sistema e verifica che i callback remoti raggiungano l'installazione corretta. Evita due database indipendenti scrivibili.
5. Abilita il nuovo negozio dopo i controlli di accettazione. Mantieni il traffico residuo su un percorso controllato o sul vecchio sistema in sola lettura fino al completamento della transizione.

Conserva una scheda del passaggio finale con l'ultimo ordine accettato dall'origine, il limite dell'esportazione finale, i risultati della riconciliazione e la persona che autorizza la riapertura. Un delta di piattaforma deve comprendere scorte modificate, ordini rettificati, annullamenti e rimborsi oltre alle nuove registrazioni. Registra i pagamenti ancora in attesa al momento dell'esportazione finale e definisci come le notifiche successive aggiornano l'ordine autorevole senza duplicare azioni di pagamento o evasione. Ripetere un'esportazione completa senza corrispondenze testate può sovrascrivere una mappatura corretta o duplicare un'importazione precedente.

Un passaggio in manutenzione comporta un intervallo di manutenzione. La cache DNS impedisce una garanzia fissa di "cinque minuti" o "zero interruzioni". La disponibilità continua richiede un approccio progettato di routing, replica e coordinamento delle scritture.

Usa i controlli di manutenzione del back office nell'ambito corretto del negozio. Nella configurazione core, PS_SHOP_ENABLE = 1 abilita il negozio; non lo mette in manutenzione.

Individua un passaggio finale non concluso in sicurezza

Esegui i controlli di lancio e recupero

• Verifica registrazione, accesso, reimpostazione password, navigazione, ricerca, filtri, combinazioni e scorte.
• Controlla aggiunte al carrello, cambi di quantità, sconti, consegna, imposte e totali in valuta come ospite e utente registrato.
• Verifica ogni metodo di pagamento con credenziali sandbox e valori di prova supportati dal fornitore, inclusi autenticazione, callback, annullamenti e rimborsi. Segui le regole del fornitore per eventuali verifiche separate in produzione.
• Conferma email di ordine e stato, messaggi di contatto, fatture e workflow di assistenza. Dopo ogni cambio del server di invio, verifica trasporto email di destinazione, SPF e DKIM su un messaggio recapitato.
• Controlla reindirizzamenti importanti, immagini, link linguistici, canonical, layout mobili e analisi.
• Svuota le cache appropriate della destinazione e ricostruisci gli indici richiesti. Rigenera le regole di riscrittura Apache dove pertinente; la configurazione Nginx richiede una revisione propria.
• Ricrea le pianificazioni cron/worker con fuso orario, percorsi e credenziali corretti. Abilita le integrazioni una sola volta e monitora errori e riconciliazione.

Mantieni disponibili la vecchia installazione e i backup per un periodo di conservazione basato sulle esigenze di ripristino. Un rollback dopo che il nuovo negozio ha accettato ordini deve preservare quelle nuove scritture. Riportare semplicemente il DNS a un database obsoleto può perdere ordini o causare evasioni duplicate.

Registra chi può fermare le scritture, dove vengono riconciliati i nuovi ordini e quale backup o delta ripristina il sistema scelto. Monitora riferimenti di pagamento, errori applicativi/server, eventi email e indicizzazione dopo il lancio.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Quali entità e campi personalizzati di origine sono inclusi, ricostruiti o esclusi e dove si trova la mappatura tra origine e destinazione?
• Quali registrazioni e percorsi cliente rappresentativi hanno superato i test con tema, moduli, mercati e ambiente concordati e dove possiamo esaminare i riscontri?
• Cosa rileva esattamente il delta finale, come vengono ritentate le righe fallite e cosa ferma ogni fonte di scrittura durante il passaggio?
• Chi è responsabile della decisione di lancio e della risposta a un pagamento fallito, un ordine mancante, un reindirizzamento non funzionante o un errore di integrazione?
• Quando il rollback richiede di riconciliare i nuovi ordini di destinazione e chi ha provato quella procedura di ripristino?
• Quali licenze ricorrenti, accessi all'archivio, account dei fornitori e responsabilità di assistenza restano dopo la consegna?

Domande dei titolari

Dobbiamo rifare il design del negozio nello stesso momento?

Ti serve un tema di destinazione compatibile quando cambi piattaforma, ma puoi mantenere navigazione, testi e identità visiva familiari. Rimanda gli esperimenti di design non pertinenti affinché i test di migrazione abbiano una destinazione stabile e i clienti possano riconoscere il negozio.

Possiamo mantenere lo stesso fornitore di pagamento?

Forse, ma mantenere il conto esercente non trasferisce l'integrazione. Conferma con il fornitore il supporto del modulo di destinazione per account, paesi e valute, poi prova credenziali, percorso delle notifiche e workflow dei rimborsi prima del passaggio.

Abbonamenti e metodi di pagamento salvati continueranno a funzionare?

Trattali come un filone di lavoro separato. Un'esportazione di clienti o ordini non dimostra che un token salvato, un mandato o un calendario di rinnovo siano trasferibili. Ottieni la procedura supportata dal fornitore e decidi quale sistema gestisce i rinnovi futuri prima di disabilitare i vecchi job degli abbonamenti.

Cosa succede a carte regalo e saldi fedeltà?

Censisci i saldi residui e le regole di utilizzo separatamente dai codici sconto. Concorda come la destinazione li registra e li riconosce, prova un utilizzo e riconcilia i saldi al passaggio finale affinché i clienti non possano spendere lo stesso credito su entrambi i sistemi.