A Magento 2 migration service moves your store from Magento 1 to Magento 2. It covers four parts: your data, your extensions and custom code, your theme, and your customizations. Adobe’s Data Migration Tool handles the data. The rest is rebuilt or replaced by developers, then tested before you switch your domain over.
Key takeaways
- Magento 2 is a rebuild, not a copy. Adobe lists four migration components: data, extensions and custom code, themes, and customizations.
- Only the data moves with Adobe’s Data Migration Tool. Themes and custom code need developer work.
- The tool runs in three modes, in a fixed order: Settings, Data and Delta.
- Test on a copy of your Magento 1 database, never on production.
- Adobe says the effort depends on how customized your store is. Be wary of any fixed quote given before an audit.
Why are stores still looking for a Magento 2 migration service?
Magento 1 stopped receiving security fixes years ago. Adobe’s security bulletin APSB20-41 says that support for Magento Commerce 1.14 and Magento Open Source 1 was ending in June 2020, and that the bulletin’s patches were the final security patches available for those editions. Several third-party sources give the exact end date as June 30, 2020, but we only confirmed the “June 2020” wording on Adobe’s own page.
Stores that still run Magento 1 are running without security fixes from Adobe. That’s the reason most owners start searching for a Magento 2 migration service, and it’s also why the work tends to be urgent once it starts.
There are other reasons too. Some merchants want a faster storefront. Some need integrations that older code can’t support. Others simply find that their developers no longer work on the old platform. Whatever your reason, the first step is understanding what moves, what doesn’t and what has to be rebuilt.
If you’re not sure whether you need a migration, an upgrade or an update, our explainer on the difference between Magento upgrade, update and migration is a good place to start. Moving from Magento 1 is a migration. Moving between Magento 2 versions is an upgrade.
What does a Magento 2 migration service include?
A complete Magento 2 migration service covers an audit, a data migration, extension and custom code work, a new or adapted theme, testing, and a launch plan. Adobe breaks the technical work into four components. Knowing them lets you check any quote against what you actually need.
Here are the four components in Adobe’s documentation, with what each means for you.
Data
Adobe built the Data Migration Tool to move products, customers, orders, store configurations, promotions and more into Magento 2. This is the most automated part of the job. It’s also the part with the most documentation.
Extensions and custom code
Magento 1 extensions don’t run on Magento 2. Adobe says it worked with the development community to help merchants use their Magento 1 extensions in Magento 2, and it points to the Commerce Marketplace, where you can download or purchase current versions of extensions. Custom code written for your Magento 1 store has to be rewritten for Magento 2.
Themes
Magento 2 uses new approaches and technologies, so Adobe says developers must make changes to themes. A Magento 1 theme can’t be dropped into Magento 2. It needs to be rebuilt or replaced.
Customizations
Your store’s custom behavior, such as special checkout rules, pricing logic or integrations, also needs developer work. Adobe says documentation exists for creating Magento 2 themes, layouts and customizations.
The takeaway: a good migration service will ask about all four components before it quotes. If a proposal only mentions “data migration,” ask who is handling the other three.
What does the Data Migration Tool actually do?
The Data Migration Tool is a command-line tool from Adobe that transfers data from Magento 1 to Magento 2. According to Adobe’s documentation, it also checks that the database structures match, tracks progress, writes logs and runs verification tests. It moves data. It does not move your theme or custom code.
Adobe describes a clear structure for how the tool works. It’s worth understanding even if you never run it yourself, because it helps you read a provider’s plan.
The three modes
The tool splits the work into three modes, and Adobe says they must be run in this order:
- Settings mode migrates system configuration and website-related settings.
- Data mode migrates database assets in bulk.
- Delta mode migrates incremental changes since the last run, such as new customers and orders.
Delta mode matters for go-live. Your Magento 1 store keeps taking orders while you test the new one. Delta mode lets the new store catch up on what changed during that time.
Steps and stages
Within each mode, the tool runs a list of steps. For example, Adobe says Settings mode uses two steps, a Stores step and a Settings step. Each step runs three stages in a fixed order:
- Integrity check: compares table field names, types and other details to confirm the Magento 1 and Magento 2 structures are compatible.
- Data transfer: moves the data table by table.
- Volume check: compares record counts between tables to confirm the transfer worked.
Map files
At the lowest level are XML map files. They tell the tool how to turn Magento 1 data structures into Magento 2 ones. Adobe gives an example: when a table was renamed, the map file renames it in the destination database. If nothing differs, the tool transfers the data as-is, including data from tables created by extensions.
One detail is worth remembering. When differences aren’t declared in the map files, Adobe says the tool shows an error and doesn’t start. That’s a safety feature, but it also means custom tables or fields need attention before you run a full migration.
Which Magento 1 versions can be migrated?
The tool supports migration from specific versions. Adobe’s “Supported versions for data migration” page, last updated July 14, 2026, lists them:
| Source edition | Supported versions |
|---|---|
| Adobe Commerce (Magento 1) | 1.11.x, 1.12.x, 1.13.x, 1.14.x |
| Magento Open Source | 1.6.x, 1.7.x, 1.8.x, 1.9.x |
Adobe also says that if you migrate from Magento Open Source to Adobe Commerce, the Open Source versions 1.6.x to 1.9.x are supported. For the Magento 2 versions you can migrate to, Adobe points to the Data Migration Tool’s release page. We didn’t confirm the destination version list, so check that page before you plan.
If your store runs a version outside those lists, ask your migration provider how they’d handle it. We can’t say from the documentation what the options are.
How does a Magento 2 migration service work, step by step?
A typical migration follows the same arc: audit, plan, build, migrate, test, launch and monitor. Adobe’s documentation covers the data part in detail. The rest is standard project practice, and we’ve marked which is which so you know what’s documented and what’s our guidance.
- Audit your Magento 1 store. List the version, extensions, custom modules, theme, integrations and data volume. This is standard practice, not a documented Adobe step.
- Choose the target. Decide between Adobe Commerce and Magento Open Source, and pick the Magento 2 version. Our comparison of Adobe Commerce, Magento Open Source and Mage-OS helps with that choice.
- Clean your data. Adobe recommends removing outdated and redundant data from your Magento 1 database before migration, such as logs, order quotes, recently viewed or compared products, visitors, event-specific categories and promotional rules.
- Copy the database. Adobe says to use a copy of your Magento 1 database for migration testing, not the production database.
- Build the Magento 2 store. Install Magento 2, add or rebuild extensions, and build the theme. Standard practice.
- Run Settings mode, then Data mode. Run the tool’s modes in the order Adobe specifies.
- Test. Check products, customers, orders, pricing, checkout and integrations. Standard practice.
- Run Delta mode before launch. Catch up on orders and customers added since the last run.
- Go live. Reindex, switch DNS and warm the cache. Adobe’s estimate is that downtime is a few minutes to reindex and change DNS, plus extra time to warm the page cache.
- Monitor after launch. Watch errors, orders, search traffic and speed.
If you’re comparing proposals, look for these stages. A proposal that skips testing or Delta mode is incomplete.
What does Adobe recommend for a smoother data migration?
Adobe’s best-practices page, last updated July 14, 2026, gives specific advice. Three points stand out.
First, use a copy. Adobe says to use a copy of the database from your Magento 1 instance when performing migration testing, and not the production database. This protects your live store and lets you re-run tests as many times as you need.
Second, clean up. Remove outdated and redundant data before you migrate. Adobe lists logs, order quotes, recently viewed or compared products, visitors, event-specific categories and promotional rules as examples. Less data means a faster, cleaner transfer.
Third, enable a performance option. Adobe suggests turning on the direct_document_copy option in the tool’s config.xml file to boost performance. It adds a requirement: both the Magento 1 and Magento 2 databases must be on the same MySQL server, and the database account must have access to both.
Those details are technical, but they’re good questions to put to a provider. Ask whether they test on a copy, whether they clean data first and how they handle the database setup.
How long does a Magento 2 migration take?
It depends on your store, and no honest provider can give you a number without looking at it. Adobe states that the level of effort depends on how you built your site and how customized it is, just as it does when upgrading between Magento 1 versions.
Adobe does publish one benchmark for the data portion. It tested a system with a database of 177,000 products, 355,000 orders and 214,000 customers. The environment was a VirtualBox VM running CentOS 6 with 2.5 GB of RAM and one 2.6 GHz CPU core. The results were:
- Settings migration: about 10 minutes
- Data migration: about 9 hours, covering all data except URL rewrites, which Adobe says is roughly 85% of the total data
- Site downtime: a few minutes to reindex and change DNS, plus time to warm the page cache
Please read that carefully. It measures one tool run on one test system. It doesn’t include building the theme, rebuilding extensions, testing or fixing issues, which are usually the larger part of the project. Don’t use it to estimate your total timeline.
For a wider view of how long a build can take, see our post on how long it takes to build a Magento store. Use it as context, not as a quote.
Which Magento 2 version should you migrate to?
Pick a current release line that has plenty of support left. Adobe’s “Released versions” page, last updated August 12, 2026, lists the dates for Adobe Commerce.
| Release line | Regular support | Extended support |
|---|---|---|
| 2.4.9 (released May 12, 2026) | Ends May 31, 2029 | Not listed |
| 2.4.8 | Ends May 31, 2028 | Not listed |
| 2.4.7 | Ends May 31, 2027 | Ends May 31, 2028 |
| 2.4.6 | Ended August 11, 2026 | Ends August 31, 2027 |
These dates apply to Adobe Commerce. We haven’t confirmed whether Magento Open Source follows the same schedule, so check that if you plan to use the free edition.
Why this matters: migrating onto a release line that’s already past regular support means you may face an upgrade soon after launch. It’s usually less work to land on a current line. Our summary of what changed in Magento 2.4.9 shows what the newest line brings, and the piece on extended support versus upgrading can help if you’re weighing an older line.
You should also confirm the Data Migration Tool supports the destination version you pick. Adobe directs readers to the tool’s release page for that, and we haven’t confirmed the current list.
What happens to your extensions?
Extensions are often the biggest surprise in a migration. Magento 1 extensions don’t carry over as they are. For each one, you have three options.
- Replace it with a Magento 2 version from the Commerce Marketplace or from the extension’s vendor. Adobe points merchants to the Marketplace for current versions.
- Rebuild it as custom Magento 2 code if no suitable version exists.
- Drop it if you no longer use the feature.
Adobe notes that the Data Migration Tool transfers data from tables created by extensions as-is when there are no structural differences. That helps, but it doesn’t mean the extension itself works in Magento 2. The data may arrive while the feature still has to be installed or rebuilt.
Our guide on when you need Magento extension development can help you decide between buying and building. Start with an inventory: list every extension, what it does, whether you use it and whether a Magento 2 version exists.
What about your theme and design?
The theme is a separate decision. Because Magento 2 uses new approaches and technologies, Adobe says developers must change themes to take advantage of them. In practice you have a few routes: adapt a ready-made theme, commission a custom one or choose a modern frontend approach.
If you’re weighing the default Luma theme against Hyvä, our Hyvä vs Luma comparison covers performance and cost. We don’t repeat its figures here.
One planning point: theme work runs in parallel with data work. Don’t leave the design until after the data is moved, or the launch date will slip.
What about SEO and URLs during migration?
Preserve your URLs where you can, and redirect the ones you can’t. This is our general guidance, not a documented Adobe step, but it protects the search traffic you’ve built.
A sensible checklist looks like this:
- Export your current URLs and note which ones get traffic.
- Keep the same URL structure where it makes sense.
- Map old URLs to new ones with permanent redirects when they change.
- Carry over page titles, meta descriptions and structured data.
- Re-submit your sitemap after launch and watch for crawl errors.
Notice that Adobe’s benchmark excluded URL rewrites from the main data figure, which suggests they’re handled differently from other data. We can’t say more from the documentation, so ask your provider how URL rewrites will be migrated and checked.
How do you compare Magento 2 migration services?
Compare them on scope, process and proof, not just price. A useful way to do this is to give each provider the same brief and see what comes back.
Ask these questions:
- Which of the four components (data, extensions and code, theme, customizations) are included in your quote?
- Will you migrate a copy of our database first, and will you clean old data beforehand?
- How do you handle extensions with no Magento 2 version?
- What’s your plan for Delta mode and the cutover? How much downtime do you expect?
- Which Magento 2 version will we land on, and when does its support end?
- How will you handle URLs and redirects?
- What testing do you do, and who signs it off?
- What happens in the first 30 days after launch?
- Who owns the code, the hosting accounts and the documentation at the end?
Watch for providers who quote a fixed price before looking at your store. Adobe itself says the effort depends on customization, so a quote with no audit is a guess.
You can also read how we approach this on our Magento 2 migration and upgrade services page. If your decision is broader than migration, our guide on how to choose a Magento development company covers the wider checklist.
How much does a Magento 2 migration service cost?
We can’t give you a reliable figure. Costs depend on data volume, the number of extensions to replace or rebuild, the amount of custom code, the theme work and the testing needed. Published prices from agencies are marketing material for their own services, and we haven’t verified any of them, so we’re not quoting one.
What you can do is request an itemized estimate. A good estimate separates:
- Audit and planning
- Data migration and testing
- Extension replacement or rebuilding
- Theme design and build
- Customization work
- Quality assurance
- Launch and post-launch support
If a provider gives you a single number with no breakdown, ask for the breakdown. It’s the easiest way to compare two quotes fairly.
What do most Magento 2 migration guides miss?
From the guides we reviewed, a few gaps keep appearing.
They skip the source of truth. Many guides describe the process from memory. Adobe’s own documentation spells out the modes, stages and map files, and it explains that the tool refuses to start when differences aren’t declared. That detail changes how you plan custom tables.
They treat migration as only data. Adobe’s four components make clear that extensions, themes and customizations need separate work. Guides that focus only on the tool leave buyers underbudgeted.
They give timelines with no basis. Adobe’s own benchmark covers only the data run on a specific test system. Many guides present timelines without saying what they include.
They ignore the target version’s support dates. Moving to a release line that’s already out of regular support creates a second project.
They forget the cutover. Delta mode and the DNS switch are where launches succeed or fail, yet they get a line or two in most guides.
Common mistakes to avoid
Testing on production. Use a copy of your database. Adobe says so directly.
Skipping the data clean-up. Logs, quotes and old promotional rules add weight to the transfer and rarely add value.
Assuming extensions will work. They won’t. Inventory them early and check each one.
Leaving the theme until last. Run it in parallel with the data work.
Ignoring Delta mode. Without it, orders placed during testing can be lost at cutover.
Choosing a version that’s about to lose support. Check the dates on Adobe’s page before you commit.
Forgetting redirects. Broken URLs cost traffic. Map them before launch.
No post-launch plan. The first weeks reveal issues no test can. Agree who responds and how fast.
A short glossary
- Data Migration Tool: Adobe’s command-line tool for moving data from Magento 1 to Magento 2.
- Mode: an ordered set of operations in the tool (Settings, Data, Delta).
- Step: a task within a mode that defines what kind of data moves.
- Stage: a task within a step that validates, transfers or verifies data.
- Map file: an XML file that defines how Magento 1 data maps to Magento 2 structures.
- Delta migration: a run that copies changes made since the last run.
- Cutover: the moment you switch traffic from the old store to the new one.
Frequently asked questions
What is a Magento 2 migration service?
It’s a service that moves your store from Magento 1 to Magento 2. It covers your data, extensions and custom code, theme and customizations. Adobe’s Data Migration Tool handles data transfer, while developers rebuild or replace the other parts and test everything before launch.
Can I migrate from Magento 1 to Magento 2 myself?
You can run Adobe’s tool yourself if you have developer skills, since Adobe documents the process. But the tool only moves data. Extensions, themes and custom code still need Magento 2 development, so most stores bring in help for those parts.
Which Magento 1 versions can be migrated?
Adobe lists Adobe Commerce 1.11.x to 1.14.x and Magento Open Source 1.6.x to 1.9.x as supported source versions for the Data Migration Tool. For supported destination versions, Adobe refers readers to the tool’s release page, which we haven’t confirmed.
Do I lose my orders and customers when I migrate?
Not if the migration is planned properly. The tool moves products, customers, orders and more, and it verifies record counts. Delta mode then catches changes made after the main transfer. Always test on a database copy and verify the numbers before launch.
How long does the data migration take?
It depends on data volume and your setup. In Adobe’s published test, with 177,000 products, 355,000 orders and 214,000 customers, the data mode took about nine hours on a small test system. That excludes theme, extension and testing work, so don’t treat it as a project timeline.
Will my Magento 1 extensions work in Magento 2?
No, they need Magento 2 versions or rebuilt code. Adobe points merchants to the Commerce Marketplace for current extension versions. The tool can move data from extension tables, but the extension itself still has to be installed or rewritten.
How much downtime should I expect at launch?
Adobe estimates a few minutes to reindex and change DNS settings, plus extra time to warm the page cache. Your own downtime depends on your setup and cutover plan, so ask your provider to describe it in writing.
Should I migrate to Adobe Commerce or Magento Open Source?
It depends on your needs and budget. Adobe Commerce is the paid edition and Magento Open Source is the free one. Our Adobe Commerce, Magento Open Source and Mage-OS comparison sets out the differences.
Where to go from here
A good Magento 2 migration service starts with an audit and ends with a monitored launch. Between those points, it handles four components, tests on a copy of your data and plans the cutover with care.
If you’d like help scoping a migration, you can read about our Magento 2 migration and upgrade services or look at our wider Magento development services. Bring your extension list and your Magento 1 version, and the conversation will be faster.