Magento Open Source migration services

What a Magento Open Source migration involves

A Magento Open Source migration moves four kinds of data and assets: catalog, customer, order and content records, plus the storefront theme and the extensions that depend on them. Each has its own mapping work. Catalog data needs product types, attributes, categories and media mapped to Magento's model. Customer and order records need field-level mapping, password handling decisions and a clear rule for which historical orders are imported and which are only archived. Content such as CMS pages and blocks is often the simplest part, but it still has to be checked for broken links and embedded assets.

The starting point changes most of this work. Typical sources are Magento 1, another ecommerce platform, or a hosted store builder. Magento 1 is a different codebase with a different data model, so its extensions rarely carry over and most custom modules must be rewritten. Other platforms use their own product and order structures, which means the mapping rules are new each time. Hosted store builders often limit data export, so the team may need to pull records through APIs or CSV exports and accept gaps. Ask each source for a full export of products, orders, customers, URLs and extension data before estimating anything.

Target the currently supported 2.4.x release line rather than an older patch. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, and the release notes for 2.4.9 cite support for PHP 8.5. Check the end of support date for the release you select, because a store launched on a line near retirement starts its next upgrade under time pressure. A migration is the cheapest point to pick the version, since the new PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and nginx versions are set up once, not retrofitted later.

In-house or partner? Teams with experienced ecommerce engineers can usually run the data mapping and extension decisions themselves. Many choose a partner for the full cutover, redirect mapping, and payment and ERP re-connection. Those areas cause most failed launches: a missing 301 redirect erodes search rankings, and a broken payment or ERP connection stops orders on launch day. Ask any quote to name who owns the redirect map, the cutover checklist, the rollback plan and the test of live payments.

What the work includes

A migration partner typically runs these workstreams in order, with each one ending in a deliverable you keep. The exact scope, sequence and effort depend on your catalog, integrations and current platform, and are fixed in writing before work starts.

Discovery and data audit

The partner inventories the current store: catalog structure, customer and order volumes, installed extensions, payment and shipping methods, ERP links and custom code. The output is a written audit that shows which data is worth moving, which is stale, and which integrations must be rebuilt. Check that the audit covers every system that reads from or writes to the store.

Target architecture and environments

The partner designs the target Magento Open Source environment, including web, database, search, cache and queue services, and the development, staging and production layout. The deliverable is an architecture document and a built, reproducible environment. Confirm that PHP, database, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions match the Adobe system requirements for the release you select.

Data mapping and transformation

Products, categories, customers, orders and CMS content are mapped field by field from the source platform to Magento's data model. The deliverable is a field-level data map with transformation rules and exception lists for records that do not map cleanly. Ask for sample migrated records to review before the full run.

Theme and storefront build

The storefront is built on a Magento theme, either custom or adapted, with templates, layouts and checkout flows rebuilt for the new platform. Design decisions about custom modules versus theme changes affect how easily later upgrades apply. The deliverable includes the theme code in version control and a page-by-page build record. Confirm which design elements are being carried over and which are being changed.

Extension mapping and replacement

Each extension on the source store is matched to a Magento Open Source equivalent, a native feature, a custom module or a decision to drop it. The deliverable is a list of retired extensions with the reason for each, plus the replacement plan. Check each replacement for upgrade compatibility and security maintenance before you commit to it.

Payment, ERP and shipping reconnection

Payment gateways, ERP sync, shipping carriers and tax services are reconnected to the new store and tested end to end with sandbox credentials. The deliverable is an integration test record covering orders, stock, invoices and refunds. Ask who owns the credentials, who signs off each connector, and how sync failures are reported after launch.

URL redirect mapping

Every indexed URL on the old store is mapped to its closest new equivalent, including products, categories, CMS pages and filtered listings. The deliverable is a redirect file, reviewed for chains, loops and unmapped pages that return errors. Ask for the redirect file in a format your team can load and test before cutover.

Test migrations and rehearsals

The full data migration is run more than once against a copy of production data to measure errors, runtime and gaps. The deliverable is a rehearsal log for each run with reconciliation counts and open defects. Confirm how many rehearsals are included in the agreed scope and who decides when the data is acceptable.

Performance and security checks

Before launch, the store is load tested, checked for cache and indexing behavior, and reviewed for hardening, including admin protection, file permissions and Content Security Policy for payment pages. The deliverable is a findings report with fixes applied or accepted risks signed off. Ask which tests are included and which are left to your own security team.

Cutover runbook and hypercare

A step-by-step cutover runbook covers DNS changes, final data delta, redirect activation, rollback criteria and who approves each step. After launch, the partner provides a defined hypercare period to resolve defects and watch error logs and orders. The deliverable is a tested runbook and a hypercare exit report. Confirm the hypercare window, its hours and its exit criteria in the written scope.

What drives cost and duration

The table lists the factors that change migration effort, why each one matters for a Magento Open Source move, and how to keep it under control before quoting.

Driver	Why it matters	How to keep it down
Source platform and version	Magento 1, another ecommerce platform or a hosted builder each need different extraction, data mapping and rebuild work, and older source versions often mean more custom code to reproduce.	Confirm the exact source version and export options early, and decide whether the target is a full rebuild or a data move with selected features.
Products, variants and images	Large catalogs with many configurable variants and high image counts increase mapping, cleanup, image processing and indexing time during test cycles.	Remove discontinued SKUs, agree a variant structure before build, and set image size and naming rules at the source.
Customer and order history volume	Millions of orders or accounts extend extraction, transformation, reconciliation and the time needed for each trial load.	Decide which order history must move, archive older records to a read-only store, and migrate only the fields the storefront and ERP use.
URL count and SEO importance	Every indexed URL that changes needs a redirect rule and validation, and a large or search-driven store carries more risk if redirects break.	Export the current URL inventory from analytics and search console data, prioritize redirects by traffic, and test them before cutover.
Third-party extensions	Each extension may need a replacement, a configuration match or a custom rebuild on the new platform, and some have no equivalent.	Run an extension inventory early, mark keep, replace or remove for each one, and avoid moving extensions that duplicate core features.
Custom functionality to rebuild	Bespoke pricing, checkout rules, catalog logic and admin workflows must be designed, built and tested again rather than copied.	Document existing behavior, cut features that are no longer used, and agree acceptance criteria per feature before estimating.
ERP, payment, shipping and tax integrations	Each integration needs mapping, credentials, sandbox access and end-to-end testing, and vendor onboarding can run on a separate timeline.	Confirm vendor sandbox availability and API limits at scoping, and list which integrations keep the same contract and which change.
Number of storefronts, languages and currencies	Each store view, language pack, currency and tax rule multiplies content, pricing data and test scenarios.	Limit launch scope to the storefronts and locales that generate revenue, and add the rest in a later phase.
Environments and test cycles	Repeated trial migrations, staging refreshes and user acceptance rounds add time, and each cycle must reproduce production data.	Agree the number of trial loads and test rounds in writing, and automate the migration script so each run takes less effort.
Compliance scope for card and personal data	Moving stored cards, customer personal data or payment tokens can bring systems into PCI DSS or privacy scope and add evidence work.	Avoid migrating stored card data, use hosted payment fields where possible, and map where personal data flows before design starts.
Data quality in the source	Duplicate customers, broken category trees, orphaned orders and inconsistent attributes are often the largest unknown and can change the plan after build begins.	Run a data profiling assessment before any quote is final, and ask the implementer to state which data issues are in scope and who fixes them.

Migration phases and outputs

The sequence below moves catalog, customer and order data and SEO URLs onto Magento Open Source in controlled, repeatable test runs before a single cutover.

Audit source data and discovery
Your team and DeployOpen inventory the source platform, its catalog, customers, orders, content, URLs and installed extensions, then profile data quality such as duplicate SKUs, orphaned records and missing attributes. The output is a data audit with record counts and totals per entity, plus a list of data that will be dropped, archived or migrated. The step is done when the business signs off which history must come across.
Choose target architecture and version
The team selects the Magento Open Source release line and the supported PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions from Adobe's system requirements for that release. Adobe lists support windows per 2.4.x release, so the choice is checked against the end of regular support date. The output is an architecture decision record covering hosting layout, environments and the version matrix.
Write mapping specification and extraction scripts
DeployOpen maps each source field to a Magento attribute, category, customer or order structure and documents every transformation, default and exception. Extraction and import scripts are built against that specification and kept under version control. The output is a signed mapping specification and scripts that run from a repeatable source snapshot.
Build storefront and theme
Storefront templates and the theme are built as custom Magento themes and modules that follow Adobe's component structure, so catalog pages, checkout and content render with the migrated data. Design decisions are kept separate from data migration so that a theme change does not force a re-import. The output is a working theme on a staging environment with sign-off on key templates.
Decide extension replacements and redirect map
Each source extension is kept, replaced with a Magento Open Source compatible package, or dropped, and each decision is recorded with its owner. In parallel, every old URL is matched to its new target, including category, product and CMS pages, and unmatched URLs are reviewed. The outputs are an extension decision log and a redirect map ready for test imports.
Run test migrations and reconcile
Full test imports run against staging, and each run produces a reconciliation report comparing record counts, order totals, tax and stock figures and customer counts against the source audit. Mismatches are logged, fixed in the scripts and re-run until the variance is explained and accepted. The number of runs is set by how many defects surface, so ask for the reconciliation history before go-live.
Test performance, security and rehearse cutover
Load, cache, search and security tests run against the staging stack, including checks on Content Security Policy, admin protection and payment page behavior. The cutover is rehearsed end to end using a timed runbook covering DNS, data freeze, final sync, redirect activation and rollback. The outputs are test results, a rehearsed runbook and a go-live checklist signed by the business owner.
Cut over and hold hypercare
On the agreed date, the source freeze, final delta import, reconciliation and redirect activation run from the rehearsed runbook, followed by a defined hypercare period with monitoring and triage. The step closes when the reconciliation report for live data is accepted and the hypercare exit criteria are met. Duration of hypercare depends on the agreed scope and should be confirmed in the written plan.

What to keep in-house and what to outsource

This table compares, for each migration work area, what the merchant team usually keeps, what a partner usually carries, and the skills each side needs, so you can see where decisions stay with your staff and where delivery work moves out.

Work area	Usually kept in-house	Usually outsourced	Skills required
Business rules and catalog ownership	Decide attribute sets, category structure, pricing rules, tax and B2B terms, and which SKUs and bundles stay live	Document current rules from the old platform and turn your decisions into a written configuration spec	Merchandising expertise, pricing and tax knowledge, product data governance
Data mapping and transformation	Decide which historical orders, customers and products are worth keeping and how long records must be retained	Write mapping rules, transformation scripts, import tooling and reconciliation reports between source and target	Magento data model knowledge, SQL and scripting, data quality analysis
Redirect mapping	Decide which old URLs matter for search traffic, campaigns and bookmarks, and approve the target for each one	Build the redirect map from crawl and analytics exports, load it into the store and test each rule before launch	SEO technical analysis, web server rewrite rules, log and crawl analysis
Storefront design	Own brand, layout priorities, content and the approval of every page template before build	Build the theme, components and responsive templates, and test them across browsers and devices	Frontend development, Magento theme structure, accessibility and performance practices
Custom module development	Approve business requirements for each custom feature and accept the test results against them	Design and build custom modules following Magento's module structure, with automated tests and upgrade notes	PHP, Magento module and dependency injection patterns, testing frameworks
Extension replacement	Decide which old extensions are still needed and which features can be dropped or changed	Find compatible Magento Open Source extensions or write replacement code, and check each one for security and upgrade fit	Extension vetting, Magento coding standards, security review
Payment and ERP reconnection	Approve payment providers, ERP fields and sync rules, and sign off on order and stock behavior	Configure gateways, connectors and queues, then test authorization, capture, refunds and failed-sync handling	Payment gateway integration, ERP interfaces, message queue design, PCI DSS scope awareness
Load and security testing	Set acceptance criteria for peak traffic and approve results, including any known risks	Run load tests against a production-like environment, perform security checks and report findings with fixes	Load testing tools, web application security testing, Magento hardening
Cutover execution	Make the go or no-go decision, approve freeze windows and communicate to customers and staff	Run the final data sync, DNS and redirect changes, smoke tests and rollback steps according to the agreed runbook	Release management, DNS and CDN operations, incident response
Staff training	Choose who must be trained, own the admin procedures and set content and order-handling policies	Prepare admin guides, recorded walkthroughs and hands-on sessions for catalog, order and content tasks	Instructional design, Magento admin workflows, process documentation

What goes wrong and how to prevent it

Most failed Magento Open Source migrations fail at the edges: URLs, data, extensions, payments and cutover timing. Each risk below names the preventive step and the evidence to ask for before launch.

URL equity lost without redirects

Old product, category and content URLs stop resolving when the new store goes live unless every one is mapped to a new destination first. Build a complete old-to-new URL map from the live site and crawl logs, test each redirect on staging, and ask for the map, the crawl report and the list of URLs returning errors after launch.

Orders and customers that do not reconcile

Order counts, totals, tax lines, customer records and open invoices can drift between the source platform and the new store. Agree reconciliation rules before the first trial import, compare record counts and financial totals by period, and ask for a signed reconciliation report covering orders, customers and addresses.

Passwords that cannot move unchanged

Password hashes from another platform may use a format Magento Open Source does not verify, so customers may need a reset flow after cutover. Decide whether to force resets, use a password-reset email campaign or a fallback login path, and ask the partner to document how each customer account type will authenticate on day one.

Extensions with no target equivalent

Features that worked through a source-platform add-on may have no matching Magento Open Source extension, or the matching one may not support the target version. Inventory every active extension and integration, map each to a replacement, custom module or removal, and ask for a written decision list with the compatibility check for each chosen package.

Payment and tax settings untested after cutover

Gateway credentials, webhook URLs, shipping rules and tax tables are often reconfigured by hand and never run end to end on the live domain. Test authorization, capture, refund, declined payments and tax calculation for each market on the production configuration before go-live, and ask for the test log with transaction IDs.

Theme rebuilt without business rules

A new theme can drop layout behavior the business depends on, such as pricing display by customer group, promotional banners, content blocks or conditional checkout messages. Write down these rules from the current store before design starts, then verify each one against the new theme in a staging review with the business owners, and ask for the signed rule checklist.

DNS and TTL problems at cutover

Long DNS TTL values, forgotten subdomains, certificate renewals and mail records can delay or split traffic during the switch. Lower TTLs well before the change window, prepare certificates for every hostname, and ask for a cutover runbook listing each DNS record, its owner, the rollback step and the verification command used after switching.

Launch before extensions are confirmed

Scheduling the go-live date before the target Magento Open Source version and its extensions have passed compatibility testing forces teams to launch with unverified code. Confirm each extension and custom module against the chosen 2.4.x release and its PHP and service versions in staging, then ask for the compatibility matrix and a go or no-go record signed before the change window opens.

How the work changes by starting point

Magento 1 is a re-platform, not a version bump. The data structure, theme layer and extension set all change, so most of the effort goes into rebuilding what the old store relied on rather than copying it across.

Data model: Map Magento 1 entities, attributes, customer groups and order history to the Magento Open Source structure, and decide which historical records to carry over.
Extensions: Inventory every installed Magento 1 extension and find a Magento 2 replacement, a native feature or a reason to drop it.
Theme: Treat the storefront as a new build, since Magento 1 themes do not carry over.
URLs: Plan redirects from old product, category and CMS URLs so search rankings are preserved.
Questions first: Which customer and order history must be retained, and which custom modules still run the business?

What you need to provide

A fixed-scope quote for a Magento Open Source migration depends on what you can hand over before work starts. Missing inputs are the most common reason a scope grows after signature, so the list below should be treated as a precondition, not a wish list. Ask for read access to the source platform, either direct database access or export tools that produce complete catalog, customer and order extracts, and confirm that the export covers attributes, media, and order history rather than only the front-end view.

Provide a full inventory of installed extensions and custom code, plus a representative sample of products, customers and orders, including configurable products, bundles and multi-store data where they exist. Add current URL and SEO data: a crawl of every indexed URL, the redirect map if one exists, and exports from analytics and Google Search Console. These drive the redirect plan and the extension replacement list, so incomplete exports translate directly into unplanned work.

List every payment, ERP, shipping and tax integration with its endpoints, sandbox availability and credentials handling method, and confirm who can issue new API keys. Decide your hosting and environment layout early, including whether the target runs on your cloud accounts or in your data center, and which environments (development, staging, production) exist. Name one business owner each for catalog, pricing, customer data and final sign-off, and agree in writing who approves each phase and who holds the cutover runbook during launch.

Decisions to make before the quote: a content and catalog freeze window for cutover, with a named owner who can enforce it; and a list of historical data you must keep, such as order history, tax records, or customer communications, along with retention rules that apply to each. Confirm with your legal and finance teams which records they require, since those choices change export volume, storage and test effort. Your partner can then write these into the fixed scope and the cutover plan.

Frequently asked questions

How is the cost of a Magento Open Source migration set?

The cost is set by a written scope, not a published price list. Cost follows the drivers: the volume of catalog, customer and order data, how many integrations must be rebuilt or replaced, how many extensions need a replacement, the number of URLs to map for redirects, and how many test cycles the cutover plan needs. Work is usually one-time, while hosting, patching and extension licenses recur. Ask any partner for a quote that lists each deliverable, the test cycles included, who performs the data mapping, and which costs recur after launch. DeployOpen does not publish prices. A quote follows from the written scope.

Can our own team migrate to Magento Open Source without a partner?

Yes, a team can migrate in-house if it has ecommerce engineers who know Magento's data model, and enough time for repeated test cycles. The hard part is rarely the first import. It is validating catalog, customer and order data after each dry run, rebuilding payment and ERP connections, and checking redirects before launch. If your team lacks that experience or cannot free people for several rounds of testing, a fixed-scope engagement with a partner can cover those phases. Either way, agree on exit criteria for each test cycle before work begins.

How long does a Magento Open Source migration take?

Duration is set by data volume, the number of integrations, and the number of test cycles, and the scope confirms the timeline. A store with a small catalog and few integrations moves faster than one with years of orders, custom attributes and a live ERP connection. Ask for a timeline that shows the discovery phase, data mapping, each rehearsal import, integration testing, the cutover window and a rollback step. Be cautious of any timeline quoted before someone has inspected your data and integrations.

Can customer passwords and order history move to Magento Open Source?

It depends on the source platform, the export format and how passwords were stored, so it must be tested before you rely on it. Some platforms export password hashes that Magento can verify, while others do not export them at all, which forces customers to reset passwords. Order history usually transfers as records, but line items, tax details, payment references and status histories may need custom mapping. Run a full rehearsal import, sign in with a sample of real customer accounts from a copy of production data, and reconcile order totals against the source system.

Can we keep our existing URLs and search rankings after migrating?

Yes, in most cases, if you build a mapped redirect file before launch. List every indexed URL from the old store, map each one to its new equivalent, and set permanent (301) redirects for changed paths. Include product, category, CMS and filter URLs, and check them against sitemaps and analytics. Test the redirects on staging with a crawler, then review the Magento URL rewrites after cutover. Search rankings depend on more than URLs, so keep content, metadata and internal links consistent as part of the same plan.

Which Magento Open Source version should we target, and does DeployOpen issue compliance certificates?

Target a currently supported 2.4.x release line and confirm its end of support date before you commit. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, and the release schedule lists end of regular support dates for each line, so confirm the current date for your chosen version. On compliance, DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies perform those assessments.

How DeployOpen delivers migrations

DeployOpen plans, builds, documents and hands over Magento Open Source migrations inside infrastructure you control, working from a written scope agreed before any build starts. Each migration is handled as a set of tested data moves, extension decisions and a cutover plan rather than a single import.

How we scope

Inventory the source platform, including catalog, customer, order and content data, and the extensions that must be replaced or dropped.
Agree in writing which data sets move, how URL redirects are mapped for SEO, and which legacy behavior is intentionally left behind.
Confirm the target Magento Open Source version against Adobe's published support dates and system requirements before the build begins.

How we build

Build repeatable data import scripts for products, customers and orders, and run them against copies of production data before any cutover rehearsal.
Replace or rebuild extension functions as custom modules, following Magento's modular structure, so later upgrades stay manageable.
Test redirect maps, payment and checkout flows, and search indexing in a staging environment that matches the planned production layout.

How we hand over

Document the cutover runbook, rollback steps, data reconciliation reports and the redirect map so your team can repeat or audit the move.
Deliver environment configuration, deployment steps and the list of custom modules, themes and replaced extensions with their owners.
Walk your internal team through the admin, operations and patching tasks they will own after go-live.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope migration work.
Plan post-cutover monitoring of redirects, order flow and search results, with issues reviewed against the agreed scope.
Confirm with us in writing which patch and upgrade tasks a retainer covers before the migration engagement closes.