Migrating a store to Magento 2 – data, integrations and SEO

The scope can cover product data, customers, orders, content, sales rules, the frontend, integrations, SEO and analytics. Before a schedule is prepared we establish which elements are migrated, rebuilt or left outside the new store. The target platform — catalogue, cart and admin panel — can be checked in the Magento 2 demo.

We have moved stores off Magento 1, off CS Store and off SaaS platforms. How it runs, though, depends not on the name of the source system but on the form in which it hands over its data — an export, an API or a direct read from the database. The individual projects are described in the source platforms section on this page.

Yes. In the SklepBaterie.pl migration we moved customer accounts and orders together with the catalogue, the CMS content and the blog. Passwords usually do not come across in readable form, so the plan has to cover how customers log in for the first time in the new store. Some historical data can also stay in an archive if it is not needed day to day.

No. Data needed in current sales should either be in the new platform or remain available in the source system. Some historical data can go into an archive if it is not needed for day-to-day service.

Yes. The new Magento 2 is built alongside the store that is still selling, and that store keeps selling until the switchover. Before launch we agree how to handle the data created between the main migration and the launch of the new platform — orders, customers, stock and prices.

Technical downtime depends on the source platform, the volume of data and how the integrations work, so we do not declare its length before a trial migration and switchover testing. It is the trial migration that shows how long the final synchronisation takes and what genuinely has to be stopped.

Yes. A map of old and new addresses and a list of 301 redirects are prepared, and with them the metadata, canonicals, sitemap and indexing rules. After launch we monitor server responses, indexing errors and traffic on the most important pages. The whole scope is set out in the SEO migration section.

It can, and often it is worth it, because a migration is the one moment when such a change does not need a project of its own. There is one condition: the new structure has to be built together with the redirect map, before the catalogue import starts. A change discovered after launch means a second round of redirects and a second drop in visibility.

Yes. Magento 2 has a different architecture, so the theme, the modules and the customisations of Magento 1 cannot be carried over as they are — the data moves, the code is written again. We rebuild the features on Magento 2 and usually build the frontend on Hyvä. It is also the moment to drop modules the store has stopped using.

That depends on their current architecture, the available API, the documentation and the target split of responsibility between systems. Some connections can be adapted, others require a new integration.

Selected elements of the identity and the user experience can be kept. A migration is also an opportunity to put the information structure, the checkout and the features that cause problems in the current store in order.

The largest influence comes from the volume and quality of the data, the integrations, custom processes, the target sales model, the number of markets, the frontend and the scope of testing. The number of products alone is not enough to assess the cost.

A schedule can be prepared once the scope has been inventoried. A store with a simple catalogue and a few integrations will need a different plan from a platform serving several markets, a B2B model and extensive warehouse processes.

With a simple sales model, few integrations and a need to launch quickly, a smaller platform can be easier to maintain. The assessment should also take in the capabilities of your team and the growth plan for the coming years.