Scegliere l’approccio di migrazione giusto per Adobe Commerce richiede una decisione sul modello operativo, non soltanto sul numero di record. Adobe Commerce può combinare configurable Products, più website, store e store view, account Company B2B, shared catalogs, prezzi specifici per Company, Customer Groups, contenuti programmati, attributi personalizzati, integrazioni e record posseduti da estensioni. Il percorso di servizio deve distinguere quali strutture rientrano nei dati standard supportati, quali richiedono configurazione sul piattaforma di destinazione, quali possono essere gestite con Add-ons circoscritti e quali necessitano di una revisione su misura tramite Custom Service.
Un progetto Adobe Commerce di grandi dimensioni non richiede automaticamente il servizio più complesso. Standard Service può restare appropriato quando il percorso di migrazione è supportato, i record di origine usano strutture riconoscibili e il cliente può gestire e validare il servizio in autonomia. Managed Service acquista valore quando coordinamento e carico di validazione sono elevati. Gli Add-ons rispondono a esigenze specifiche e supportate di filtraggio dei record, trasformazione dei valori o rimappatura dei campi. Custom Service è il corretto percorso di escalation quando il risultato richiesto dipende da record non supportati, moduli personalizzati, trasformazioni su misura, strutture B2B non standard, identificatori di sistemi esterni o logica di migrazione personalizzata.
Nel modello dei Next-Cart Migration Services, queste evidenze separano ambito supportato, responsabilità di esecuzione, esigenze circoscritte degli Add-ons e requisiti Adobe Commerce su misura.
Partire dal modello operativo Adobe Commerce
I progetti Adobe Commerce devono essere classificati in base al modello operativo che la piattaforma di destinazione dovrà sostenere. Uno store B2C monobrand con un solo website e Products convenzionali genera una decisione diversa da un’implementazione enterprise con più website, store regionali, store view, Company, shared catalogs, prezzi per acquirente e sistemi ERP/PIM strettamente collegati.
Adobe Commerce usa una gerarchia website, store e store view. I website possono avere domini e ambito del processo di acquisto distinti. Gli store possono usare root Categories separate. Le store view supportano spesso lingue o presentazioni differenti. Gli shared catalogs B2B possono controllare Products e prezzi visibili alle Company assegnate. Queste sono strutture architetturali della piattaforma di destinazione, non semplici etichette applicate ai record migrati.
| Domanda sul modello operativo | Segnale di minore complessità | Segnale di maggiore complessità |
|---|---|---|
| Ambito website/store | Un website, uno store, poche store view | Più website, store regionali, root Categories diverse, domini separati o configurazioni specifiche per ambito |
| Struttura catalogo | Simple/configurable Products con attributi riconoscibili | Bundle, grouped Products, tipi Product personalizzati, attribute set complessi, contenuti programmati o relazioni create da estensioni |
| Modello Customer | Customers e Customer Groups ordinari | Company, Company users, shared catalogs, prezzi negoziati, permessi, credito o flussi di approvazione |
| Responsabilità integrazioni | Pochi riferimenti esterni | ERP, PIM, OMS, WMS, CRM, marketplace, imposte, pagamento o evasione degli ordini che controllano valori critico per l’attività |
| Personalizzazione | Campi standard e record supportati | Moduli personalizzati, colonne database, tabelle di estensioni, API personalizzate, flussi su misura o identificatori esterni |
L’approccio deve essere scelto dopo aver documentato questo modello. In caso contrario, un progetto può essere trattato come normale trasferimento catalogo mentre l’azienda si aspetta che B2B enterprise e comportamento multi-site diventino operativi automaticamente.
Quando Standard Service può essere la scelta giusta
Standard Service è adatto quando il percorso dalla piattaforma di origine ad Adobe Commerce è supportato, i dati sono accessibili tramite una connessione supportata e il risultato richiesto rientra nel comportamento standard di migrazione. Con questo servizio Next-Cart, il cliente resta responsabile di preparazione, dettagli di connessione, scelte di configurazione, decisioni di esecuzione e validazione.
Un buon candidato Standard Service presenta normalmente:
- ambito chiaro per Products, Customers, Orders e contenuti;
- tipi Product e relazioni varianti riconoscibili;
- SKU e identificatori Product coerenti;
- Categories, attributi e valori attributo comprensibili;
- normali record Customer e indirizzi;
- Orders storici che non dipendono da contesto nascosto in sistemi esterni;
- destinazione website/store/store view definita;
- nessuna aspettativa che estensioni, moduli B2B o integrazioni vengano ricostruiti tramite la migrazione standard dei record;
- un team in grado di esaminare in dettaglio Demo Migration e Full Migration.
Standard Service non va escluso soltanto perché il catalogo è grande. Il volume viene gestito tramite l’Entity Points Plan selezionato. La domanda più importante è se i record restino all’interno di strutture supportate e se il cliente possa validare il risultato in autonomia.
Il servizio diventa meno adatto quando Products dipendono da tipi personalizzati, i prezzi Company sono memorizzati fuori da strutture B2B riconoscibili, identificatori esterni controllano il evasione degli ordini oppure l’azienda presume che configurazione della piattaforma di destinazione e implementazione dei moduli seguano automaticamente dal trasferimento dei dati.
Quando Managed Service è più sicuro
Managed Service è appropriato quando la migrazione resta in larga misura nel comportamento supportato ma il cliente ha bisogno che gli specialisti Next-Cart gestiscano l’esecuzione e forniscano coordinamento strutturato. Può ridurre la pressione operativa in progetti con cataloghi grandi, più team aziendali, finestre di lancio rigide o elevata responsabilità di validazione.
Managed Service è spesso più sicuro quando:
- volume di catalogo, Customers e Orders crea un carico di revisione elevato;
- più website, store o store view devono essere validati da responsabili diversi;
- i team business hanno bisogno di una pianificazione coordinata della migrazione;
- stakeholder B2B, regionali o di canale devono approvare campioni rappresentativi;
- i dati di origine sono comprensibili ma abbastanza incoerenti da richiedere revisione operativa attenta;
- l’azienda non riesce a gestire con sicurezza configurazione ed esecuzione da solo;
- la finestra di lancio richiede issue tracking ed escalation controllati.
Managed Service non espande automaticamente il supporto standard della piattaforma. Cambia chi gestisce esecuzione e coordinamento. Se il risultato richiesto include strutture Company non supportate, dati di moduli personalizzati, trasformazioni su misura o relazioni esterne non standard, può essere comunque necessario Custom Service per tali requisiti.
Una regola utile è separare carico di esecuzione da carico di personalizzazione. Managed Service affronta il primo. Custom Service affronta il secondo. Alcuni progetti enterprise richiedono entrambi: esecuzione gestita e personalizzazioni definite separatamente.
Dove si inseriscono gli Add-ons
Gli Add-ons sono appropriati quando la migrazione principale resta standard ma un requisito circoscritto e supportato modifica il risultato desiderato. Per Adobe Commerce, i controlli rilevanti riguardano filtraggio dei record tramite condizioni sui campi per ciascun tipo di dati, trasformazione dei valori mediante espressioni e rimappatura dei campi di origine.
Esempi Adobe Commerce possono includere:
- applicare condizioni sui campi Product per escludere Products inattivi o obsoleti;
- applicare condizioni sui campi Customer o Order per escludere Customers di test o Orders storici irrilevanti;
- usare espressioni per trasformare valori di campi supportati durante la migrazione;
- rimappare campi standard supportati di Product, Category, Customer o Order verso campi di destinazione compatibili mantenendo invariato il valore;
- conservare informazioni selezionate di contenuto o SEO quando il percorso di migrazione lo supporta;
- usare Data Filter, Advanced Data Mapping o Data Transformation per un’esigenza supportata e ben definita.
Gli Add-ons non devono diventare un’etichetta generica per ogni requisito complesso di Adobe Commerce. Rimappare un campo supportato è diverso dall’estrarre record da un modulo B2B personalizzato. Filtrare vecchi Orders attraverso una condizione sui campi Order è diverso dal ricostruire un flusso di approvazione Company. Il primo può rientrare in un Add-on; il secondo richiede revisione Custom Service o implementazione separata sul piattaforma di destinazione.
Il confine corretto è se il requisito resta dentro il comportamento di migrazione supportato. Se sì, un Add-on può bastare. Se richiede estrazione, trasformazione, logica o interpretazione di responsabilità non standard, appartiene alla revisione Custom Service.
Quando considerare Custom Service
Custom Service va considerato quando il risultato richiesto non può essere ottenuto con record standard supportati e Add-ons circoscritti. Adobe Commerce genera spesso questa necessità attraverso ecosistema di estensioni, strutture B2B, ambito multi-site e dipendenze da sistemi esterni.
Segnali tipici di escalation includono:
- tipi Product o relazioni personalizzate creati da moduli;
- attributi personalizzati che richiedono trasformazione di destinazione su misura;
- Company, Company users, shared catalogs o prezzi negoziati memorizzati in strutture non standard;
- campi personalizzati del processo di acquisto o dati Order in tabelle di estensione;
- identificatori ERP, PIM, OMS, WMS, CRM, imposte o evasione degli ordini da preservare in uno specifico campo destinazione;
- regole su misura per l’allocazione website/store/store view;
- record non supportati da marketplace, subscription, loyalty, quoting, approval o returns modules;
- colonne database personalizzate, API o tabelle di integrazione;
- una Custom Platform su uno dei due lati del percorso;
- requisiti che modificano la logica standard di migrazione.
Custom Service non include automaticamente sviluppo di moduli Adobe Commerce, installazione di estensioni, configurazione B2B, setup shared catalog, costruzione website/store view, implementazione theme, configurazione pagamento/shipping, distribuzione delle integrazioni o ricostruzione completa dello store di destinazione. Queste responsabilità sono incluse soltanto se concordate esplicitamente nell’ambito del servizio.
Entity Points e pianificazione dell’ambito enterprise
Gli Entity Points forniscono un quadro di capacità per i record idonei migrati. Nelle attività successive sullo stesso percorso Adobe Commerce, i record idonei già conteggiati restano conteggiati una sola volta; complessità legate a website, store view, B2B ed estensioni vengono valutate separatamente. Categories, attributi, Company, shared catalogs, website, store view, campi personalizzati, moduli e identificatori esterni possono aumentare la complessità senza diventare tipi di record Entity Points separati.
Questa distinzione è fondamentale. Due progetti possono usare lo stesso Entity Points Plan ma richiedere percorsi di servizio molto diversi. Un grande catalogo di Products ordinari può rientrare in Standard Service. Un catalogo più piccolo può richiedere Custom Service se ogni Product dipende da attributi personalizzati, prezzi per Company o identificatori controllati da integrazioni.
Nelle attività successive sullo stesso percorso, Products, Customers, Orders o Blog Posts idonei creati dopo la precedente migrazione possono consumare Entity Points quando vengono migrati per la prima volta.
| Domanda di pianificazione | Perché conta |
|---|---|
| Quali record idonei sono inclusi nell’ambito approvato? | Determina l’Entity Points Plan appropriato. |
| Quali record sono obsoleti, duplicati o non necessari al lancio? | Supporta le decisioni di filtraggio ed evita consumo non necessario di capacità. |
| Quali record sono già stati conteggiati nella migrazione acquistata e nel percorso fisso? | Evita ipotesi errate di doppio consumo. |
| Quali nuovi record idonei potrebbero essere creati prima del lancio? | Supporta la pianificazione della capacità per attività successive. |
| Quali strutture complesse non sono tipi Entity Points separati? | Mantiene separati complessità e volume. |
Gli Entity Points aiutano a dimensionare la migrazione. Non dimostrano che requisiti B2B, multi-site, estensioni o integrazioni siano supportati.
Cosa deve dimostrare Demo Migration
Demo Migration deve testare la scelta del percorso di servizio con record rappresentativi e difficili. Selezionare soltanto simple Products può creare falsa fiducia in un progetto Adobe Commerce.
Il campione dovrebbe includere, quando rilevante:
- simple, configurable, bundle, grouped, virtual o downloadable Products;
- Products con attributi complessi e valori specifici di store view;
- Categories usate da store o root catalog diversi;
- Customers di gruppi importanti o contesti Company;
- Orders con sconti, imposte, rimborso, stati insoliti o identificatori esterni;
- CMS Pages, Blog Posts e record sensibili agli URL ad alta priorità;
- record influenzati da estensioni o integrazioni;
- esempi per ogni website, store o store view importante al lancio.
Demo Migration deve rispondere a quattro domande:
- I record standard sono rappresentati correttamente?
- Le relazioni di ambito store e B2B mantengono il loro significato?
- Quali lacune possono essere risolti tramite configurazione supportata o Add-ons?
- Quali lacune richiedono Custom Service o implementazione separata sul destinazione?
Una Demo Migration riuscita non è soltanto un confronto di conteggi. Fornisce evidenza che il percorso di servizio scelto è abbastanza solido prima di Full Migration. Se il campione rivela strutture non supportate o responsabilità nascoste, l’approccio deve cambiare prima dell’esecuzione completa.
Additional Migration Options per Adobe Commerce
Le Additional Migration Options supportano attività successive quando la sorgente resta attiva, cambia la configurazione della piattaforma di destinazione o l’azienda necessita di un risultato di migrazione diverso. L’azione selezionata deve riflettere se la configurazione precedentemente accettata sia ancora valida.
| Azione corrente | Situazione appropriata | Focus della revalidazione Adobe Commerce |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Mappatura e ambito accettati restano validi e nuove attività della sorgente devono essere elaborate con la stessa configurazione. | Nuovi Products, Customers, Orders, Blog Posts, valori store ambito, URL e identificatori collegati alle integrazioni. |
| Continue the Migration with a New Configuration | Il percorso resta lo stesso, ma filtraggio, mappatura, assegnazione store o altra configurazione supportata deve cambiare. | Strutture Product modificate, allocazione website/store/store view, mappatura attributi, ambito B2B, contenuti e URL. |
| Perform a New Migration | L’azienda necessita di un risultato distinto anziché continuare la configurazione precedente. | Intero ambito piattaforma di destinazione, gerarchia B2B/store, modello Product, responsabilità integrazioni, SEO e criteri di accettazione. |
Queste azioni non implementano automaticamente moduli Adobe Commerce, shared catalogs, Company permissions, integrazioni esterne, theme o configurazione della piattaforma di destinazione. Operano all’interno dell’ambito del Migration Service concordato e mantengono invariato il percorso Source Platform → Target Platform acquistato. Per cambiare Source Platform o Target Platform serve un altro Migration Service acquistato.
Decisione finale sul percorso di servizio
L’approccio migliore è il percorso di servizio più leggero che riesce a mantenere il significato aziendale richiesto e a produrre un risultato che l’azienda possa validare con sicurezza.
| Evidenza | Approccio probabile |
|---|---|
| Record supportati, strutture ordinarie, ambito chiaro, esecuzione e validazione gestite dal cliente | Standard Service |
| Ambito supportato ma coordinamento, validazione o pianificazione del lancio impegnativi | Managed Service |
| Migrazione standard con esigenze circoscritte e supportate di filtraggio record, trasformazione valori o rimappatura campi | Standard o Managed Service con Add-ons |
| Record non supportati, moduli personalizzati, trasformazioni su misura, complessità B2B o integrazioni fuori dal comportamento standard | Custom Service, potenzialmente con Expert Handle e Add-ons concordati |
La decisione va documentata prima di Full Migration e confermata dalle evidenze di Demo Migration. Un progetto non dovrebbe essere portato a un servizio più complesso solo perché Adobe Commerce è enterprise, né restare su un percorso leggero quando il risultato accettato dipende da strutture enterprise non supportate.
Conclusione
La scelta dell’approccio per Adobe Commerce dipende dalla relazione tra ambito dei record, struttura operativa enterprise, responsabilità di esecuzione e personalizzazione. Standard Service può sostenere percorsi puliti e supportati. Managed Service aiuta quando coordinamento e validazione sono impegnativi. Gli Add-ons coprono esigenze circoscritte supportate. Custom Service gestisce requisiti su misura e non standard.
La decisione finale deve considerare gerarchia website/store/store view, tipi Product, contesto Company/shared catalog B2B, sistemi esterni, Entity Points ed evidenze prodotte da Demo Migration. Le Additional Migration Options vanno poi selezionate in base al fatto che la configurazione accettata resti valida, debba essere modificata o debba essere sostituita da un nuovo risultato di migrazione.
Domande frequenti
Un grande catalogo Adobe Commerce può usare Standard Service?
Sì. Il volume dei record da solo non determina il percorso. Un grande catalogo può usare Standard Service quando il percorso è supportato, le strutture Product sono riconoscibili e il cliente può eseguire e validare il servizio. Gli Entity Points gestiscono la capacità dei record idonei; la complessità strutturale viene valutata separatamente.
Quando Managed Service è più appropriato per Adobe Commerce?
Quando la migrazione resta nel comportamento supportato ma esecuzione, coordinamento o validazione sono impegnativi. È particolarmente utile per progetti multi-team, più ambito di vetrina, grandi carichi di revisione e finestre di lancio rigide.
Gli Add-ons coprono i moduli personalizzati Adobe Commerce?
In generale no. Gli Add-ons supportano esigenze circoscritte dentro il comportamento supportato. Dati in moduli personalizzati, tabelle di estensione, strutture B2B su misura o sistemi esterni richiedono di norma una revisione Custom Service.
Cosa deve dimostrare Demo Migration per Adobe Commerce?
Che Products, Customers, Orders, contenuti, ambito store, relazioni B2B, URL e campi collegati alle integrazioni restino significativi. Deve inoltre chiarire se i lacune appartengono a configurazione, Add-ons, Custom Service o implementazione separata sul piattaforma di destinazione.
Quale Additional Migration Option va scelta?
Usare Continue the Migration with the Last Used Configuration quando il setup accettato resta valido; Continue the Migration with a New Configuration quando devono cambiare impostazioni supportate; Perform a New Migration quando serve un risultato distinto con revalidazione completa.