Migrations & upgrades
Magento migration and Magento 2 upgrades, without the drama
Whether you are leaving Magento 1, moving to Magento 2 from another platform or bringing a 2.4.x store up to a supported version, the work is the same at heart: rehearse it, test it, and protect the data and the rankings you already have.
Magento 1
Magento 1 reached end of life in June 2020. Stores still on it are exposed
Adobe ended support for Magento 1 on 30 June 2020. Since then it has published no security patches and no fixes for either Magento 1 Open Source or Magento 1 Commerce.
A Magento 1 store can keep taking orders, which is why many still do. The risk grows quietly. Community patches exist, and they are a holding position, not a plan. The route forward is a migration to Magento 2 or, for simpler catalogues, a move to Shopify.
-
No official security fixes
Vulnerabilities found since 2020 are not patched by Adobe, and unsupported stores are an obvious target for card-skimming attacks.
-
Payment compliance
PCI DSS expects supported, patched software. Running an unsupported platform makes that hard to show to your payment provider.
-
An ageing stack
The PHP versions Magento 1 was written for are themselves out of support, which limits your hosting options.
-
Extensions left behind
Most extension vendors, payment providers and carriers have stopped updating their Magento 1 modules.
Migration
What is migrated, and what is rebuilt
This applies whether you are coming from Magento 1, WooCommerce or another platform. Data moves across. Code does not.
-
Migrated
Products and catalogue
Products, categories, attributes, images, prices and stock, mapped to Magento 2’s structure and cleaned up on the way.
-
Migrated
Customers
Accounts, addresses and customer groups. Whether existing passwords carry over depends on the source platform, and we confirm that during discovery so customers are not surprised.
-
Migrated
Orders
Order history, so customers see past purchases. How far back to go is your decision.
-
Migrated
URLs and content
CMS pages, metadata and every indexed URL, either kept as it is or redirected to its new address.
-
Rebuilt
Theme
A Magento 1 or WooCommerce theme cannot run on Magento 2. The storefront is rebuilt, usually on Hyvä.
-
Rebuilt
Extensions and custom code
Each one is reviewed: replaced with a Magento 2 equivalent, rewritten as a custom module, or retired because Magento 2 does it natively.
Version upgrades
How a Magento 2 upgrade actually runs
A 2.4.x upgrade is more than a Composer command. Each release supports specific versions of PHP, MySQL or MariaDB, OpenSearch and the other services around it, so the server often has to move with the code.
-
01
Check what will break
We compare the store with the target release: system requirements, every extension’s compatible version, custom modules that use deprecated code, and any core edits left by previous developers.
- Compatibility report
- Fixed scope and price
-
02
Bring the stack into line
A staging environment is built on the PHP, database and OpenSearch versions the target release requires, using a recent copy of production data.
- Matching staging environment
-
03
Upgrade through Composer
Magento and its extensions are updated through Composer. Incompatible extensions are updated or replaced, and custom code is corrected where the framework has changed.
- Upgraded codebase in Git
-
04
Regression test
Automated tests run first. Then browsing, search, cart, checkout with each payment method, emails, admin tasks and every integration are tested by hand.
- Test report
- Your sign-off
-
05
Rehearse the release
The full deployment is run on staging from start to finish and timed, so the maintenance window is known and the rollback steps are proven.
- Launch runbook
- Rollback plan
-
06
Release and watch
The upgrade is released at a quiet time for your store, checked against a go-live list, and monitored closely for errors and failed orders afterwards.
- Upgraded live store
SEO protection
Keeping your rankings through a replatform
Most traffic lost in a migration is lost for one reason: URLs changed and nobody told the search engines. It is avoidable if it is planned from the first week.
- URL mapping. We crawl the existing site and combine it with your analytics and Search Console data to list every URL that has traffic, links or rankings.
- 301 redirects. Each URL that changes gets a permanent redirect to its closest equivalent, not to the home page. Redirects are tested in bulk before launch.
- Metadata and content. Titles, descriptions, headings, structured data and category copy are carried across.
- Canonical tags. Layered navigation and product variants are configured so they do not create duplicate pages.
- Sitemap and robots rules. A fresh XML sitemap is generated, and staging is kept out of the index.
- Search Console. The new sitemap is submitted at launch, then indexing and crawl errors are watched and fixed in the weeks after.
What is included
What you get with every upgrade or migration
Before
- Audit of code, extensions and server requirements
- Written scope with a fixed price
- A decision on every extension: keep, replace or retire
- URL map and redirect plan for migrations
During
- Staging environment that matches production
- Repeatable, scripted data migration, run more than once
- Regression testing of checkout, payments and integrations
- Outstanding security patches applied
At launch and after
- Rehearsed go-live with a runbook
- Tested backup and rollback plan
- Monitoring of errors, orders and Search Console
- Documentation of what changed
Risk
What can go wrong, and how it is controlled
| The risk | How we control it | |
|---|---|---|
| Go-live failure | The release hits a problem that staging did not show | A full backup, a written rollback plan and a go-live rehearsal, so reverting is a known procedure |
| Data drift | Orders, customers and content change while the data is being moved | A content freeze before launch and a final delta migration during the maintenance window |
| Broken extensions | A module has no compatible version for the target release | Found at the audit stage, with a replacement or rewrite scoped before work starts |
| Lost orders | An ERP, payment or shipping integration stops working quietly | Each integration tested end to end on staging and monitored after launch |
| Lost rankings | Old URLs return errors after a replatform | URL mapping, tested 301 redirects and Search Console monitoring |
No upgrade is free of risk. The aim is that nothing happens on launch day for the first time.
Questions
Magento upgrade and migration questions
Is Magento 1 still supported?
No. Adobe ended support for Magento 1 on 30 June 2020 and has released no security patches for it since. Magento 1 stores continue to run, but they rely on out-of-date software and on community patches. Merchants still on Magento 1 should plan a move to Magento 2 or to another supported platform.
Can Magento 1 be upgraded to Magento 2 automatically?
No. Magento 2 is a different application with a different architecture, so moving from Magento 1 is a migration, not an upgrade. Data such as products, customers and orders can be migrated with tooling and scripts. The theme, extensions and custom code cannot be carried over and are rebuilt or replaced for Magento 2.
How long does a Magento 2 upgrade take?
It depends on how many versions the store is behind, how many extensions are installed and how much custom code there is. A well-kept store with few extensions is a short project. A store with core edits and abandoned modules takes longer. We give a schedule after an audit, once the real condition is known.
How often should Magento 2 be upgraded?
Security patches should be applied soon after Adobe releases them, which happens several times a year. Full version upgrades should keep the store on a release line that Adobe still supports. Small, regular upgrades are cheaper and safer than one large jump after years of neglect.
Will migrating to Magento 2 affect my SEO?
A migration changes URLs, templates and page speed, so it can affect rankings if it is handled carelessly. The risk is controlled by mapping every existing URL, adding 301 redirects, carrying over metadata and canonical tags, and submitting a new sitemap in Search Console. Short-term fluctuation is normal, and lasting losses are avoidable.
Can you migrate a WooCommerce store to Magento 2?
Yes. Products, categories, customers, order history and content are exported from WooCommerce, mapped to Magento 2’s data structure and imported with repeatable scripts. The theme and plugins are not migrated. The storefront is rebuilt on Magento, and each plugin is replaced by a native feature, an extension or a custom module.