Migrazione dati da Magento 1 a Magento 2

Introduzione

Migrare i dati dalle precedenti versioni di Magento al nuovo Magento 2 è un tema molto richiesto nella community, molte persone cercano consigli, suggerimenti e recensioni sull’uso del tool sviluppato e mantenuto nel repo github di Magento (anche il team di Magento chiede a chi ha usato il tool di compilare un sondaggio per conoscerne i pareri e suggerimenti). In questo articolo ci occuperemo di scoprire, installare e dare qualche consiglio su questo strumento, così da avere una panoramica per utilizzarlo e avere qualche suggerimento da poter seguire. Non daremo spazio all’intero processo di porting di un ecommerce alla nuova piattaforma; migration plan, moduli proprietari, personalizzazioni e i temi sono tutti parte della guida alla migrazione che potrete trovare qui

Prerequisiti

Come anticipato nell’introduzione, ci occuperemo della migrazione dei dati, ovvero giocheremo solo con i database dei nostri Magento, perciò come regola generale “diamoci dentro con le copie di sicurezza dei db”.

Come prerequisiti per questo articolo dovremmo avere un’installazione di base (funzionante) di Magento 2 e l’accesso ai database di Magento 1 e 2.

Nota: Personalmente per lo sviluppo della configurazione da usare nella mia migrazione ho preferito importare il database di Magento 1 sullo stesso DBMS di Magento 2, questo perché essendo su un’altra macchina avrei aggiunto dei tempi di esecuzione in più a discapito dello sviluppo.

Il tool

Per prima cosa procuriamoci il tool da utilizzare nella nostra installazione. Per farlo ci basta seguire la guida ufficiale. Da tener presente che ogni versione di Magento 2 può avere la sua versione di migration-tool, questo è dovuto alle modifiche fatte durante i vari upgrade dei moduli.

Io ho preferito installarlo tramite il repo github aggiungendo la dipendenza al file composer.json. Una volta installato potete verificare se è presente il comando migrate nell’output di bin/magento

$ bin/magento | grep migrate
migrate
 migrate:data                              Main migration of data
 migrate:delta                             Migrate the data is added into Magento after the main migration
 migrate:settings                          Migrate system configuration

Iniziamo a vedere l’organizzazione del modulo per farci un idea più precisa di come lavorare con il tool.

Il modulo presenta tre cartelle:

• etc, contenente gli xml utilizzati dal tool con i relativi xsd per descriverne la struttura.
• src, il sorgente del tool.
• tests, contenente i vari test del modulo.

L’unica cartella realmente utilizzata da noi per effettuare la migrazione è etc. Se date uno sguardo all’interno di essa noterete subito le 3 sottocartelle dove dovrete scegliere il tipo di edizione a cui migrare partendo dalla vostra attuale. Passare alla community edition (CE) o alla enterprise edition (EE) non è l’unica scelta da fare, all’interno della cartella scelta troverete un’ulteriore diramazione dovuta a tutte le versioni di magento 1.X da qualche può essere eseguita la migrazione.

Supponiamo di partire da una Magento CE 1.9.1.0 e vogliamo migrare alla CE di Magento 2 sappiamo che dovremmo utilizzare i file presenti nel tool sotto etc/ce-to-ce/1.9.1.0

La guida di Magento 2 suggerisce di rinominare il file config.xml.dist per effettuare le dovute modifiche da utilizzare per la propria migrazione. Personalmente non ci piace molto l’idea di modificare/aggiungere un file all’interno di vendor di un namespace non nostro, così opteremo per creare all’interno di una differente cartella la struttura e i file necessari per poter proseguire.

Per la nostra prima migrazione abbiamo usato la cartella dev per ospitare tutte le modifiche, ma per quelle future useremo un nuovo repository da importare con composer.

Seguendo sempre l’abitudine di conservare la struttura delle cartelle ci ritroviamo ad avere il nostro primo file per la migrazione così:

+–dev/

| +–magento2-migration-tool

| | +–etc

| | | +–ce-to-ce

| | | | +–magento1.9.1.0

| | | | | +–config.xml

Aprendo il file config.xml come prima passo dovremmo sistemare il link al xsd.

La copia iniziale ha come valore:

../../config.xsd

e seguendo la struttura delle cartelle diventerà:

../../../../../vendor/magento/data-migration-tool/etc/config.xsd

Si è un po lungo, ma non possiamo usare l’urn come abbiamo visto nell’articolo precedente del blog perché il tool non è né un modulo Magento né tanto meno appartiene al framework (arrangiamoci con questo, e ricordiamo che se creiamo un repository per la vendor dovremmo ulteriormente modificare questo path).

Il secondo passo da fare è cambiare i dati di accesso al database, aggiungere il prefisso se gestito da Magento1 e/o Magento2 ed inserire la crypt key che potete trovare nel file local.xml dell’installazione dei Magento1.

<source>
    <database host="127.0.0.1" name="db_magento1" user="mysqluser" password="mysqlpassword"/>
</source>
<destination>
    <database host="127.0.0.1" name="db_magento2" user="mysqluser" password="mysqlpassword"/>
</destination>
<options>
    <source_prefix>mage1prefix_</source_prefix>
    <dest_prefix>mage2prefix_</dest_prefix >
    ...
    <crypt_key>qwerty1234567890</crypt_key>
    ...
</options>
...

Le modifiche fatte fin ora al file config.xml permettono di migrare un installazione di Magento1 a Magento2 a condizione che non ci siano personalizzazioni. Se volete, potete provare a migrare un installazione di Magento1 con i sample data chiamando

$ php bin/magento migrate:data dev/magento2-migration-tool/etc/ce-to-ce/magento1.9.1.0/config.xml

Il comando riceve in input il file di config da utilizzare, una volta dato l’invio vedrete piano piano migrare tutti i data nel nuovo Magento2.

Funzionamento

I tre nuovi comandi del tool di migrazione consentono di eseguire 3 distinte operazioni sul nostro database, queste sono chiamate mode e sono:

• settings: per migrare le configurazioni da Magento 1 a Magento 2
• data: per migrare tutti i dati da Magento1 a Magento2
• delta: per migrare tutti i dati che sono stati aggiunti a Magento1 dopo l’esecuzione della migrazione effettuata con l’operazione precedente.

Ognuno di questi mode è a sua volta diviso in steps, questi descrivono l’ordine di esecuzione dei passi per eseguire la migrazione nel mode richiesto. Nello specifico ogni step si occupa della migrazione di una unità logica all’interno di Magento 2, come possono essere le tabelle dei clienti o degli ordini.

Ogni step può essere composto a sua volta da stage, gli stage sono di 4 tipi:

• Integration: consente di controllare se le strutture sorgente e destinazione sono compatibili per effettuare lo step.
• Data: il cuore della migrazione, questo stage consente il passaggio dei dati su Magento 2 e in caso di errori fa il rollback dei dati.
• Volume: controlla che i dati siano stati passati tutti correttamente (il più delle volte effettua il count sulle due tabelle, sorgente e destinazione, comparandone i risultati
• Delta: lo stage che si occupa di importare (o aggiornare) i dati nelle tabelle già migrate durante lo step “data”

La composizione di mode, step e stage la possiamo vedere nel file config.xml:

<steps mode="settings">
    <step title="Settings Step">
        <integrity>Migration\Step\Settings\Integrity</integrity>
        <data>Migration\Step\Settings\Data</data>
    </step>
    ...
</steps>
<steps mode="data">
    <step title="EAV Step">
        <integrity>Migration\Step\Eav\Integrity</integrity>
        <data>Migration\Step\Eav\Data</data>
        <volume>Migration\Step\Eav\Volume</volume>
    </step>
    ...
</steps>
<steps mode="delta">
    <step title="Customer Attributes Step">
        <delta>Migration\Step\Customer\Delta</delta>
        <volume>Migration\Step\Customer\Volume</volume>
    </step>
    ...
</steps>

Qui possiamo intervenire modificando gli step e aggiungendone dei nuovi a seconda delle nostre personalizzazioni

Note: Nei prerequisiti abbiamo fatto notare che per lo sviluppo abbiamo preferito avere i due db sullo stesso DBMS, ma è opportuno (una volta terminato lo sviluppo) effettuare la migrazione dal database di produzione. Questo perché l’esecuzione del mode data inserisce delle nuove tabelle e trigger all’interno di magento1 per popolarle durante il periodo di transazione dalla prima versione alla seconda. Le “operazioni” effettuate dopo la prima migrazione dei dati saranno importate nel nuovo Magento2 con l’esecuzione della migrazione con mode delta.

Personalizzare la migrazione

Come abbiamo fatto notare prima, con la sola aggiunta delle informazioni dei database potremmo migrare un Magento 1 con i sample data senza problemi, mentre per poter effettuare la migrazione delle installazioni personalizzate abbiamo bisogno di effettuare altre modificare. È possibile intervenire sulla migrazione modificando i file xml dichiarati all’interno del file config.xml.

Per questo articolo vedremo solo due esempi di modifica dei file xml: setting.xml e map.xml.

Quando abbiamo eseguito la prima volta la migrazione dei settings abbiamo notato un incredibile rallentamento di Magento2, questo era dovuto alla grande mole di configurazioni portata all’interno del database.

Quindi uno dei primi file che abbiamo dovuto modificare è stato settings.xml, per rimuovere tutti le configurazioni non più indispensabili nel nuovo ecommerce. Anche per questa modifica abbiamo preferito copiare il file in una nuova posizione al posto di modificare quello esistente.

Le modifiche che si possono effettuare permettono di aggiungere tre diverse tipologie di tag:

• ignore per ignorare una config (o una serie di esse tramite wildcare)
• rename per rinominarla
• transform per modificarne il suo valore seguendo una logica descritta in una classe

Se ad esempio volessimo ignorare tutte le config del tema, ci basterebbe aggiungere la nuova regola prendendo d’esempio una già inserita e modificando il relativo path della config:

<ignore>
    <path>design/theme/*</path>
 </ignore>

Una volta capito come aggiungerne una, possiamo andare avanti con l’aggiunta di tutte le vecchie config che non ci servono e che occuperebbero solo spazio inutile. Una volta terminate le modifiche al file, è importante dichiarare il suo path nel config.xml. Nel nostro caso modificheremo settings_map_file come segue:

<options>
    ...
    <settings_map_file>../../../dev/magento2-migration-tool/etc/ce-to-ce/magento1.9.1.0/settings.xml</settings_map_file>
    ...
</options>

Lo stesso può essere fatto per il file del map.xml che si occupa della migrazione della maggior parte dei dati. Qui le operazioni possibile sono molte di più ed è possibile vederle nella relativa documentazione. Come per settings.xml rivediamo il tag ignore che permette di ignorare sia tabelle che colonne.

Per aggiungere una regola di ignore in questo file è necessario tener conto di entrambi i database, quello sorgente e destinazione. Ad esempio se volessimo ignorare la tabella newsletter_subscriber dovremmo aggiungere:

<source>
    <document_rules>
        <ignore>
            <document>newsletter_subscriber</document>
        </ignore>
        ...
    </document_rules>
    ...
</source>
<destination>
    <document_rules>
        <ignore>
            <document>newsletter_subscriber</document>
        </ignore>
        ...
    </docuemnt_rules>
    ...
</destination>

L’aggiunta in entrambi i punti è necessaria perché il controllo sui database restituirebbe un errore per la mancata gestione della tabella.

Suggeriamo in questo file l’aggiunta di una regola di trasformazione per risolvere un bug non ancora gestito dal tool ma segnalato al team. Il bug in se non blocca l’esecuzione della migrazione ma inserisce un dato errato all’interno di Magento2, in particolare riguarda l’attributo msrp_display_actual_price_type salvato nella colonna value della tabella catalog_product_entity_varchar. La regola da aggiungere è la seguente:

...
<transform>
    <field>catalog_product_entity_varchar.value</field>
    <handler class="Bitbull\MagentoPatch\Handler\Catalog\Product\Attribute\Type\Price\ConvertMsrpPriceType"/>
</transform>
...

Magento 2 definisce la costante \Magento\Msrp\Model\Product\Attribute\Source\Type\Price::TYPE_USE_CONFIG uguale a 0 mentre la stessa costante ha valore 4 in Magento 1 ed è questo il valore che viene importato erroneamente.

La nostra trasformazione permette di sostituire il valore inesistente al corretto valore della costante. Potrete vedere il codice della classe nel commento sul bug, dove si evince che la trasformazione di questo attributo deve controllare tutte le righe della tabella per verificare quale riga rappresenta l’attributo msrp_display_actual_price_type.

Conclusioni

Noi abbiamo provato il tool per migrare una versione 1.9.1.0 sulla versione 2 di Magento, funziona decisamente bene e si presta in modo positivo alle modifiche fatte sugli ecommerce esistenti.

Logicamente non permette di portare le personalizzazioni sviluppate sulla prima versione, e se queste non devono essere integrate possiamo escluderne in modo semplice e veloce le tabelle e/o colonne interessate.

Il tool presenta sicuramente altri bug oltre quelli risolti, quindi aiutiamo la comunità e, come nel nostro caso, segnaliamo e nel caso proviamo a risolverli.

Buona migrazione.