You do not have to take your store offline to migrate from Magento 1 to Adobe Commerce. The safe approach is to build the new store in parallel while the old one keeps selling, sync data forward in repeated delta runs, and switch traffic during a short planned window. The old store stays a live fallback until the new one is proven. This guide is the playbook.
The fear that stops most Magento 1 migrations is not cost. It is the cutover. Merchants have heard the horror stories: a team flips the switch over a weekend, something breaks in checkout, orders stop, and revenue craters while everyone scrambles. That is a big-bang cutover, and it is one of the most common ways a migration fails. It is also avoidable. A phased migration treats go-live as a controlled, reversible event, not a leap of faith.
We are Bemeir, a Brooklyn ecommerce agency that has been certified on Magento since the 1.x days. We have run these migrations for US manufacturers and B2B merchants doing serious revenue, and everything below is how we actually sequence the work to protect the store while it moves.
Why “Big Bang” Is the Real Risk, Not Migration Itself
A big-bang cutover means you migrate everything at once, switch DNS, and hope. The problem is not that migrations are inherently dangerous. It is that a single, all-at-once switch concentrates every possible failure into one moment when you have no fallback. If the new store has a broken payment integration or a mispriced catalog, you find out in production, live, with real customers.
The phased alternative removes that concentration of risk. You never have a moment where the old store is gone and the new one is unproven. Instead you run them side by side, keep the data in sync, validate the new store against real traffic patterns, and only move customers once you have evidence it works. If something is wrong, you have not lost anything, because the old store is still there.
This is not a theoretical preference. Magento 1 reached end of life in June 2020 and has received no official security patches since. Thousands of unpatched Magento 1 stores have been compromised in the years since, so staying is its own risk. The goal is to move off Magento 1 without trading a slow security risk for a sudden revenue risk. Our Magento development services team scopes every migration around keeping the store trading throughout.
The Parallel-Run Model in Plain Terms
Adobe Commerce does not migrate in place. You stand up a completely separate new environment, and the old Magento 1 store keeps running untouched on its own infrastructure. Both are live at the same time. The old one takes real orders; the new one is built, populated, and tested in parallel.
The bridge between them is the official Data Migration Tool, which moves data in three stages:
- Settings mode copies configuration such as websites, stores, and system config.
- Data mode copies the bulk of your catalog, customers, and order history in one large pass.
- Delta mode captures everything that changes in Magento 1 after that first bulk pass and applies it forward to the new store.
Delta mode is the piece that makes staying live possible. When you run it, the tool installs change-log tables (prefixed m2_cl_) and database triggers in the Magento 1 database. From that point on, every new order, customer signup, review, and admin change on the old store is recorded. You run delta repeatedly, and each run carries the latest changes forward. Your old store never stops selling, and the new store never falls behind.
The Phased Sequence We Use
Here is the sequence, framed so each phase produces something you can verify before the next begins. Treat the durations as ranges for a mid-market store; a $40M US manufacturer with custom modules sits at the longer end.
| Phase | What happens | Store status | Typical duration |
|---|---|---|---|
| 1. Discovery and audit | Inventory extensions, custom code, integrations, and data quality on Magento 1 | Live, untouched | 2 to 4 weeks |
| 2. Build new environment | Provision Adobe Commerce, install a modern frontend, rebuild custom features | Live, untouched | 6 to 12 weeks |
| 3. First data migration | Run settings and data modes; validate catalog, customers, orders | Live, untouched | 1 to 2 weeks |
| 4. Integration and QA | Wire ERP, payment, tax, shipping; test every flow against real data | Live, untouched | 3 to 6 weeks |
| 5. Delta sync loop | Run delta repeatedly; keep new store current; user-acceptance testing | Live, syncing forward | ongoing until cutover |
| 6. Cutover window | Final delta run, freeze admin, switch DNS, smoke test, monitor | Brief planned window | hours, not days |
| 7. Stabilization | Old store kept warm as fallback; monitor orders and errors | New store live | 1 to 2 weeks |
The total from discovery to a stable new store typically runs four to eight months, driven by catalog size, the number of custom integrations, and B2B complexity. The important point is that the store is generating revenue for all but a few hours of that timeline.
Integrations Are Where Revenue Actually Breaks
Most migration guides treat the catalog as the hard part. In our experience the catalog is the easy part. What breaks revenue is the integration layer: the ERP that owns pricing and inventory, the payment gateway, the tax service, the shipping rate engine, and any CRM or POS that expects data in a specific shape.
A phased migration lets you test each of these against real data in phase 4, before any customer sees the new store. You place test orders that flow all the way through to the ERP. You confirm tax calculates correctly for your states. You verify that inventory sync does not oversell. None of this can be validated in a big-bang cutover, because there is no window to test it before it is live. Bemeir maintains a deep partner ecosystem across payments, ERP, tax, and shipping, and we lean on those technology partner relationships to certify each integration before go-live rather than discovering a gap in production.
For B2B merchants the integration surface is larger still. Company accounts, shared catalogs, contract pricing, requisition lists, and negotiable quotes all touch the ERP and pricing logic. Complex custom pricing is one of the most common reasons a naive cutover fails, because the new store prices an order differently than the old one and no one notices until a customer complains. Phase 4 exists to catch exactly that.
The Cutover Window, Step by Step
When the new store has passed acceptance testing and every integration is certified, the actual switch is short and reversible. Here is the sequence during the planned window:
- Announce a brief admin freeze so no new orders or catalog edits happen mid-switch.
- Run one final delta migration to carry the last changes forward.
- Verify order and customer counts match between old and new.
- Switch DNS to point at the new store.
- Run a smoke test: load the homepage, a category, a product, add to cart, and complete a test checkout end to end.
- Watch order flow and error logs closely for the first hours.
Customers keep shopping through this because the DNS switch is near-instant for most visitors and the storefront never actually goes dark. If the smoke test fails, you point DNS back at the old store, which is still running and still current, and you have lost nothing but the window. That reversibility is the entire point of the phased method.
Should You Modernize the Frontend at the Same Time?
A migration is a natural moment to also move off the legacy Luma frontend, because you are already rebuilding the storefront layer. Moving to a modern frontend during the migration avoids paying for a second project later and gives you the Core Web Vitals and mobile-speed gains at the same time. The tradeoff is scope: doing both at once lengthens the build phase. For many mid-market merchants it is worth it, because the alternative is migrating onto a slow frontend and then migrating again. We help teams weigh that decision as part of discovery rather than bolting it on late.
Frequently Asked Questions
Can I migrate from Magento 1 to Adobe Commerce without downtime?
Effectively yes. Using a parallel-run approach, the old Magento 1 store keeps taking orders while the new Adobe Commerce store is built and tested alongside it. The Data Migration Tool’s delta mode keeps the new store synced with changes on the old one. The only interruption is a brief planned window for the final DNS switch, usually measured in hours, and even then the storefront does not go dark for most visitors.
What is a phased Magento migration?
A phased migration breaks the move into discovery, parallel build, bulk data migration, integration testing, a delta sync loop, a short cutover window, and stabilization. Each phase produces something you can verify before the next begins, and the old store stays live and serving customers until the new one is proven. It is the opposite of a big-bang cutover, where everything switches at once with no fallback.
How does delta migration keep my store live?
When you run the Data Migration Tool in delta mode, it installs change-log tables and triggers in the Magento 1 database. From then on, every new order, customer, review, and admin change is recorded and can be carried forward to the new store on each delta run. This lets the old store keep selling right up to the cutover while the new store stays current, so no orders are lost in the transition.
How long does a Magento 1 to Adobe Commerce migration take?
For a mid-market store, expect four to eight months from discovery to a stable new store. The largest variables are catalog size, the number of custom integrations, and B2B complexity such as company accounts and custom pricing. A store with heavy custom modules and ERP dependencies sits at the longer end. The store keeps generating revenue for nearly all of that timeline.
What happens to my order history and customers?
Both are migrated. The Data Migration Tool moves historical orders, invoices, credit memos, and customer accounts in the bulk data pass, then delta mode carries forward anything that changes afterward. You verify counts match on both stores before cutover, so customers keep their accounts and order history on the new Adobe Commerce store.
Why not just stay on Magento 1?
Magento 1 reached end of life in June 2020 and receives no official security patches, and thousands of unpatched Magento 1 stores have been compromised since. Staying is a slow but real security and compliance risk, especially if you handle card data. A phased migration lets you retire that risk without taking on the sudden revenue risk of a rushed cutover. You can read more about our approach on the About Bemeir page.
