How to migrate from Magento 1 to Magento Open Source without losing orders or SEO
Moving a live Magento 1.6 to 1.9 store to Magento Open Source 2.4 is a documented data migration plus a rebuild of the front end and extensions. The effort is set mainly by customizations, extension count and data volume, and the number of products or orders matters less than how much of the old store was hand-built. Trading continues during the move, so the plan has to keep orders flowing into the old store until a controlled cutover. Magento Open Source 2.4.9 was released in May 2026, according to its release notes, but the newest release is not automatically the right target for your project.
Choose the exact 2.4.x release against Adobe's lifecycle policy before any build work starts. Each 2.4.x release receives three years of standard support from general availability. Adobe lists end of regular support on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. A store that goes live on a line close to its end date will need an upgrade within months, and that upgrade is a second project with its own theme and extension testing. Compare the lifecycle dates with your expected go-live window, and confirm them on Adobe's pages on the day you decide, since those pages are the authoritative source.
Once the release line is fixed, check each component against Adobe's system requirements for that line. Adobe supports only the listed combinations of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx, so your extensions and hosting must fit inside that matrix. Confirm whether your architecture needs Varnish as the full-page cache, since Adobe documents it for self-managed installations. Also review your custom checkout and payment scripts against Content Security Policy behavior. From 2.4.7, the policy runs in restrict mode by default on storefront and admin payment pages, so inline scripts that worked on Magento 1 can break a payment step after launch.
Decide early which decisions protect orders and SEO, because they are hard to reverse at cutover. Name one owner for the cutover decision, define which historical orders and customer accounts must be readable in the new store, and list every URL that must answer after launch so redirects can be planned against that list. Ask your implementation partner to state in writing how each of these items will be verified against your store before go-live, and what evidence they will hand over. If you are considering a community distribution such as Mage-OS, confirm extension compatibility and security patch timing for that distribution as well, because those details differ from Adobe's release line.
What maps from Magento 1 to Magento Open Source and what does not
This table compares each major Magento 1 data area and customization with its Magento Open Source equivalent. Read the migration note first, which says whether an item maps with mapping work, must be rebuilt, or needs a separate method. Confirm each row against Adobe's Data Migration Tool documentation before fixing the cutover plan, because the theme and extensions usually carry the most build effort.
| Magento 1 item | Magento Open Source equivalent | Migration note | Confirm against Adobe's Data Migration Tool documentation |
|---|---|---|---|
| Catalog products and attributes | Products, attribute sets and product types in the Magento Open Source catalog | Maps with mapping work. Attribute sets, product types and option values need review before the first data run. | Product and attribute field mapping, including product types and attribute set handling. |
| Categories | Category tree and category attributes in Magento Open Source | Maps with mapping work. Check category IDs, anchor settings and URL keys after the first run. | Category data handling and how category URL keys are carried over. |
| Customers and addresses | Customer accounts, customer groups and address book in Magento Open Source | Maps with mapping work. Password hashes, customer groups and address fields need checks per store. | Customer, address and password hash migration, plus customer group mapping. |
| Orders and invoices | Sales orders, invoices and status history in Magento Open Source | Needs a separate method or a documented exception for full history. Confirm which records carry forward. | Which order, invoice and status records the tool migrates, and how delta runs treat them. |
| CMS pages and blocks | CMS pages and blocks in Magento Open Source, edited through the admin | Maps with mapping work. Widget and template directive syntax in content often needs rewriting. | CMS content migration, widgets and template directives that the tool does not convert. |
| URL rewrites | URL rewrites in Magento Open Source, generated from product, category and CMS URL keys | Maps with mapping work. Plan 301 redirects for changed or retired URLs in the cutover runbook. | Which rewrites are imported and which are regenerated, and the redirect steps after cutover. |
| Store and website configuration | Stores, websites, store views and system configuration in Magento Open Source | Maps with mapping work. Many settings are renamed or moved, so each one needs a manual check. | Configuration paths the tool migrates and the paths it leaves for manual setup. |
| Magento 1 theme | A Magento Open Source theme built on the Magento 2 frontend structure | Must be rebuilt. Magento 1 templates and layouts do not carry over as working code. | Exactly what the tool migrates for design settings, and what the build team must create. |
| Third-party extensions | Magento Open Source modules or vendor packages that provide the same function | Must be rebuilt, replaced or removed. Each extension needs a Magento 2 equivalent or a custom build. | Extension data tables the tool maps, and which extension tables need custom mapping. |
Documented import and migration paths for Magento 1 stores
Adobe documents two import routes for stores moving to Magento Open Source: the Data Migration Tool for Magento 1 and the built-in CSV import. The cards below explain what each covers, which side of the migration each tool works on, and what to confirm before planning. Use them to settle the method before estimating the work.
Data Migration Tool as the primary path
Adobe documents the Data Migration Tool for Magento 1 as the path for moving a Magento 1 store's settings, data and later changes to Magento Open Source. This migration is planned around it. Before planning, the team should confirm read access to the source store database and a running Magento Open Source 2.4 target instance, since both are needed to run the tool.
What each migration run covers
The settings run carries store configuration, the data run carries the main catalog, customer and order records, and delta runs carry changes made after the previous run. Because delta runs can repeat, the cutover window only needs to cover the final delta. Confirm the exact entity list for each run in the version you plan to use, and identify any extension tables or custom attributes that need mapping, since the defaults may not include them.
Built-in CSV import for selected entities
Magento Open Source includes a CSV import for specific entities such as products and customers. Use it as a secondary path for targeted loads or for records that the Data Migration Tool does not move as needed, not as the main method for the whole store. Plan the column mapping and file preparation in advance, and check the list of supported entities in Adobe's current documentation for the target version.
Target side in Admin and command line
Once data reaches Magento Open Source 2.4, the Magento 2 Admin is used to review and check imported records and configuration, while the command line handles tasks such as indexing, cache management, module enablement and deployment. Confirm which tasks each interface supports for the target version. Decide who runs the commands during cutover and who verifies data in the Admin, since these are often different people.
Confirm supported versions first
Before planning, confirm the Magento 1 source versions and the Magento Open Source 2.4 target versions that Adobe's current documentation supports for the Data Migration Tool. The target release also sets its own requirements for PHP, the database, search, caching and other services, so check those against your hosting plan. Record the confirmed versions and the date you checked them in the migration plan, and repeat the check if the schedule changes.
Mage-OS as an alternative distribution
Mage-OS is a community distribution built on Magento Open Source, and the team may evaluate it as the target codebase. Compare its release history, security patch handling and extension compatibility with the Adobe option before deciding. Choosing it does not change the migration method: the same tool, runs, mapping and cutover steps apply, and the version checks above still govern the plan.
Rebuilding the theme and extensions on Magento Open Source 2.4
Magento 1 themes and extensions do not carry over to Magento Open Source 2.4 as they are. The Data Migration Tool moves data, not code, so the storefront and every add-on must be rebuilt or replaced on the Magento 2 side. Magento Open Source extends the platform through three component types: modules, themes and language packages. Modules follow a PSR-4 compliant structure, and Adobe's developer documentation describes this as the basis for how custom code is organized. Planning this work early matters because the theme and extensions usually account for the most build effort in the migration.
Inventory each extension first. Start with a complete list of every Magento 1 extension, local override and custom module in the live store, including the version installed and the business process it supports. For each one, check whether a Magento Open Source 2.4 version exists from the vendor and whether it matches the 2.4 release line you plan to run. Where no 2.4 version exists, the team either custom-builds a replacement module or drops the feature. Record the decision for every item, because an extension with no owner in the business is often a candidate for removal rather than a rebuild.
Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of upgrade effort. The same drivers shape the initial rebuild. A store with few extensions and little core rewriting is a far smaller job than one with dozens of modules that touch checkout, pricing or the ERP. Ask any partner to show the count of extensions, the number of custom modules and the list of third-party integrations in the written scope, and ask how each one is priced. Also ask how the team will use the Upgrade Compatibility Tool so that future patch cycles do not start from zero.
Rebuild the theme as a Magento 2 theme. Magento 1 theme files, layouts and templates do not map one to one onto Magento 2. The rebuild normally starts from the Magento Open Source base theme, carries over the brand and layout decisions, and reimplements templates in the Magento 2 structure. Confirm with the team whether the new theme is built in-house, by a partner, or from a commercial base, and who maintains it after go-live.
Plan for Content Security Policy. Adobe documents Content Security Policy headers from version 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Every inline script and third-party tag in the rebuilt theme, including analytics, chat and payment widgets, must be declared in the policy or it may be blocked in the browser. Test checkout and the payment pages in a staging environment that runs restrict mode, and record which scripts were added, why, and by whom. Treat this as a launch blocker rather than a post-launch fix.
The migration sequence: inventory, pilot, parallel run and cutover
The sequence moves a Magento 1 store onto a pinned Magento Open Source 2.4.x build in controlled stages, so each data set, integration and URL is checked before live traffic moves. The client keeps approval at each gate, and the store ends with a documented cutover and retained Magento 1 backups.
Inventory data, extensions, integrations and URLs
The client and DeployOpen list everything the Magento 1 store depends on: customer, order, catalog and CMS data, custom and third-party extension tables, cron jobs, ERP, payment, shipping and email integrations, and every indexed storefront URL. DeployOpen maps each extension to a keep, replace or retire decision with the client's business owners. The handover is an inventory workbook that the client signs off. The step is done when no table, integration or URL is unaccounted for.
Build the target on the chosen 2.4.x line
DeployOpen builds a clean Magento Open Source installation on the 2.4.x release line the client selects, in the client's own infrastructure. Component versions come from Adobe's system requirements for that line. For example, the 2.4.9 requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64, and Adobe supports only the listed combinations. The client confirms the requirements against the current release notes before ordering hardware or cloud resources. The step is done when the empty store passes health checks, indexers run and the admin login works.
Run the settings and data pilot in non-production
DeployOpen runs the Data Migration Tool against a copy of the Magento 1 database inside a non-production environment, then applies the extension table mappings from the inventory. The pilot covers store configuration, customer accounts, orders, catalog and CMS content, and it produces a report of row counts, skipped records and mapping exceptions. The client reviews the exceptions with the business owners and confirms how each one is resolved. The step is done when the pilot report is accepted and every exception has a documented decision.
Repeat delta runs to track ongoing changes
While the Magento 1 store keeps trading, DeployOpen runs repeated delta migrations that copy only the orders, customers, catalog changes and content created since the previous run. Each run produces a delta log, and mapping fixes found in one run are carried into the next. The client confirms which data changes are still arriving in the live store and which teams need to be told about the migration schedule. The step is done when consecutive delta runs produce small, explainable changes and the logs show no open errors.
Validate orders, customers and catalog in parallel
The client's operations, customer service and merchandising staff check the migrated store against the Magento 1 store side by side. They compare sample orders and their totals, tax and shipping lines, customer logins and addresses, product prices, stock, attributes and category structure, and they test the storefront URL redirects from the inventory. DeployOpen logs each defect, fixes it, and reruns the affected delta. The handover is a signed validation checklist with the defect log closed. The step is done when the client accepts the checklist results for every area in scope.
Run the final delta and cut over
At an agreed window, the client stops write activity on the Magento 1 store, DeployOpen runs the final delta, and the client switches traffic to Magento Open Source. The team applies the URL redirects, confirms DNS and certificates, and runs test orders through the live payment and shipping integrations before real customers return. The rollback point and the decision owner are written into the cutover runbook before the window opens. The step is done when the runbook records the final delta result, the test orders and the go-live approval.
Decommission Magento 1 and keep backups
After the cutover has been stable for the period the client's policy sets, the Magento 1 store is switched to read-only and taken offline. DeployOpen hands over a backup of the Magento 1 code, database and media files, and the client keeps those backups under its own retention schedule. Access to the old store is removed from integrations and staff accounts. The handover is a decommission record listing what was archived, where it is stored and who owns it. The step is done when the record is signed and the backups are confirmed restorable.
Final delta, URL redirects and the cutover window
The final delta run is the step that moves the last orders, customers, stock changes and content edits from the Magento 1 store into the new Magento Open Source 2.4 instance, and it is the point where the project stops being a copy and becomes a cutover. Everything earlier in the migration runs against a store that is still taking trade, so each incremental run can only approximate the live data. The final run needs the source store to stop accepting changes for long enough to capture a consistent set of records. Before the run, the team should agree with the business which write paths must stop: checkout, admin order edits, customer registration, catalog and price updates, and any scheduled jobs or ERP syncs that write to the Magento 1 database.
Placing the store in a controlled state is therefore a business decision as much as a technical one. Options typically include a maintenance page on the Magento 1 storefront, a temporary disable of checkout with a notice, or a short window in which catalog changes are frozen by process. Each option has a different customer impact and a different risk of orders landing in the old system after the delta has run. Confirm with your hosting provider and change-management process exactly how the freeze is applied, who approves it, how long the team is authorized to hold it, and how the freeze is lifted if the cutover is aborted. Record the final order and customer identifiers captured by the delta so the reconciliation after go-live has a fixed reference point.
URL redirects are the second part of the window. Magento 1 product, category and CMS URLs will not all match the paths generated by Magento Open Source, and search engines and external links still point at the old addresses. Build a redirect map from the Magento 1 URL rewrite data to the new URL keys, then review every exception: renamed categories, merged products, removed CMS pages and any custom routes from your extensions. Load the map into the new store's URL rewrite tooling or your web server layer, and test a representative sample of old URLs from logs and analytics, including URLs with parameters and pagination. Each test should confirm a single 301 hop to the correct destination, with no redirect chains and no 404 responses for pages that are still live.
Before go-live, check that search engine and analytics behavior matches the new store. Confirm that the staging robots directives are removed, that noindex settings from pre-launch testing are reversed, and that the XML sitemap is generated for the new URLs and submitted in the relevant search console tools. Confirm that analytics and tag manager containers fire on the new domain and pages, that e-commerce events carry the expected order values, and that consent logic still applies. Do not treat these as cosmetic checks, because a missed noindex or an unreviewed redirect can cost search visibility for weeks. The DNS change, rollback path and sequencing of these steps should be confirmed with your hosting and change-management teams before the window is booked, and this page does not give a cutover duration.
Effort drivers in a Magento 1 to Magento Open Source migration
This table lists the drivers that most change the effort of a Magento 1 to Magento Open Source migration and what to request in a written quote. The migration itself is a one-time project, while patching and upgrades on the new platform recur, so ask each quote to price the two separately. Read each row against your own store and identify which drivers are strongest before comparing quotes.
| Driver | Why it changes effort | What to ask for in a quote |
|---|---|---|
| Number and age of extensions | Each Magento 1 extension needs a Magento Open Source replacement, a rewrite or removal, and testing. Older or unmaintained extensions often take the longest to replace. | An inventory of every extension with its version and owner, plus the replacement or removal plan for each one. |
| Degree of theme customization | A heavily customized Magento 1 theme cannot be carried over unchanged, so templates, layouts and front-end code are rebuilt for the new platform. | Whether the theme is rebuilt or ported, which page templates are in scope, and who approves the visual design. |
| Custom modules and checkout changes | Custom modules are rewritten to the Magento Open Source module structure. Checkout changes need the most regression testing before cutover. | A module-by-module estimate, a list of checkout flow changes, and test cases covering payment and tax paths. |
| Third-party integrations (ERP, payment, shipping, search) | Each integration needs its own field mapping, credentials, sandbox testing and cutover step. ERP and payment links usually need the most testing. | Each integration listed with its owner, test environment access, and the cutover steps the vendor must support. |
| Order and customer volume | Higher volumes lengthen the initial data run, each delta run and validation. They also extend the final delta at cutover. | Record counts for orders, customers and products, the number of delta runs planned, and the cutover window assumed. |
| Number of store views and websites | Each store view and website adds configuration, catalog scope, pricing and URL mapping that must be verified. | The store views and websites in scope, which settings are shared, and how URL redirects are tested for each store. |
| PCI DSS scope changes | A new hosting model or payment flow can change which systems fall into cardholder data scope, and the evidence for the assessor must be rebuilt for the new environment. | A scope statement for the target environment, any payment method changes, and who produces the evidence for the assessor. |
| Hosting model and cache choices | Self-managed installations need a chosen full-page cache. Adobe documents Varnish for self-managed installations, so Varnish configuration, tuning and purge rules add work. | Whether Varnish is configured and tuned, who manages cache purges, and the load testing scope before cutover. |
| Content volume | CMS pages, blocks, media files and SEO metadata must be moved, mapped and checked. Large media libraries extend transfer and validation time. | Counts for pages, blocks and media files, whether media is copied or referenced, and how content is checked after cutover. |
What usually goes wrong in a Magento 1 migration and how to prevent it
Most Magento 1 migrations that run late or fail at cutover trace back to a small set of predictable gaps. The six risks below cover data, URLs, extensions, the theme, connected services and the rollback path, and each has a check the team can run before the final delta.
Orders and customers during the delta gap
The live Magento 1 store keeps taking orders, customer accounts and stock changes after the first data run. Each delta run carries only what changed since the previous run, so the team must confirm which entity types each delta includes and when the final delta runs. Before cutover, run a full rehearsal delta, compare order and customer counts on both sides, and agree in writing who freezes the old store and when.
Lost SEO equity from missing redirects
Changed URL structures for products, categories and CMS pages can drop search rankings and break inbound links. Build a redirect map from a full export of the Magento 1 URLs, including paginated, filtered and legacy patterns that still receive traffic. On staging, test a sample of high-traffic and heavily linked URLs for the expected status codes, confirm the sitemap lists only new URLs, and keep the map under version control so reviewers can check it alongside catalog changes.
Extensions with no 2.4 equivalent
Many Magento 1 extensions were never ported to Magento 2, and some ported versions lack features the store depends on. Inventory every installed extension with a named business owner, then classify each as core functionality, replacement, custom rebuild or retirement. Check each candidate against the exact 2.4 release line you plan to run and against the vendor's current support status, because a gap found after the build starts moves both schedule and budget.
Theme rebuild scope underestimated
Magento 1 themes do not carry over to Magento 2 unchanged, so the storefront is usually rebuilt. Scope depends on custom templates, layout XML, checkout modifications and third-party widgets, which teams often count late. Ask for an inventory of page types (home, category, product, cart, checkout, account and CMS) and of custom blocks before agreeing scope. Confirm the rebuilt pages work with the Content Security Policy headers the release runs, since 2.4.7 applies restrict mode on payment pages by default.
Integration and payment endpoints left on the old store
ERP, shipping, tax, payment, email and analytics connectors often hold the old store's base URLs, API credentials or webhook addresses. List every connector, reconfigure each for the new environment, and test with sandbox credentials before cutover. Payment flows also need a PCI DSS scope review, because a change in hosting or payment handling can change which systems store, process or transmit cardholder data. Ask your payment provider and your qualified security assessor to confirm that scope in writing.
No tested rollback path
Cutover needs a documented route back to the Magento 1 store, covering DNS changes, database snapshots and how orders placed on the new platform are handled if you return. Rehearse the rollback on staging, record who makes each decision, and confirm the old store can be reopened without losing data. Confirm the target stack matches a combination Adobe supports for your chosen release, such as the PHP, MySQL or MariaDB, OpenSearch and Redis or Valkey versions listed for that line, before the rehearsal begins.
Questions buyers ask before migrating from Magento 1
How much does a Magento 1 to Magento Open Source migration cost?
The cost depends on the written scope, and no single figure applies to every store. The main components are discovery and data mapping, configuring the Data Migration Tool runs, rebuilding the theme and extensions on Magento Open Source 2.4, testing, cutover support and URL redirects. Your partner is paid for the build work defined in the scope. Your organization pays for hosting, any paid extensions, and internal staff time. Most of the migration cost is one-time, while hosting, search and cache services, and patching or upgrade work recur. Ask for each component as a separate line, the number of extensions in scope, which customizations will be rebuilt or dropped, what testing is included, and what is excluded. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes from that scope.
How long does a Magento 1 to Magento Open Source migration take?
Duration follows the scope you agree, mainly the size of the catalog and order history, the number of custom extensions and theme changes, the number of integrations to re-point, and how many stores and languages you run. Data quality and how quickly your integration owners answer also matter. The work runs in passes: settings, a first data run, delta runs while the live store keeps trading, then a final delta at cutover. Each pass adds verification time. DeployOpen does not publish a fixed duration. Ask for a timeline tied to written milestones and to the freeze window your business can accept, and ask which critical-path items depend on your people, such as sign-off on catalog data or sandbox access for payment testing.
Can our in-house team migrate Magento 1 to Open Source alone?
A capable team can attempt it alone, but general Magento knowledge is not enough on its own. The work involves PHP and the Magento 2 module structure (PSR-4 modules, themes and language packages), MySQL administration, and server setup for PHP, OpenSearch, Redis or Valkey, RabbitMQ and nginx, with Varnish for self-managed caching. Extension tables need careful mapping in the Data Migration Tool. Adobe documents the Data Migration Tool and the Upgrade Compatibility Tool, which help with the work but do not replace testing. Check whether your team has run a cutover with delta runs, can rebuild or retire each extension, and can own production afterwards. Many organizations keep business sign-off in-house and bring in specialists for mapping and cutover.
What does a Magento 1 migration need from our own staff?
The migration needs four things from your side: data access, a complete extension list, named integration owners, and sign-off. For data access, provide read access to the Magento 1 database and file system, a staging environment, and a copy of the media files. The extension list should include every installed module, its version, whether the vendor still maintains it, and the business process it supports. Name one owner each for ERP, payment, shipping, tax and marketing connections, with authority to test in sandboxes and approve credential or URL changes. Sign-off should come from business owners for catalog, pricing, customer accounts, order history and redirects, with a dated acceptance step before cutover. Name a decision-maker who can approve scope changes. Without these, delta runs and testing stall.
Should we choose Magento Open Source or Mage-OS for our store?
Choose Magento Open Source if you want Adobe's own release line, documentation and published support dates for each 2.4.x release. Choose Mage-OS if you prefer a community-owned distribution built on Magento Open Source and run by the Mage-OS Association, which describes itself as upstream compatible with Magento 2 extensions and lists releases that port Adobe security patches. Decision factors include your extension list and whether each vendor supports the distribution, who you want to depend on for security patch timing, your internal policy on community versus vendor-backed software, the hosting and search stack you run, and how confident your team is verifying each release. Confirm extension compatibility and patch timing with the distribution and with your extension vendors before you commit to either path.
What happens after go-live on Magento Open Source?
Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches ship at least annually for all supported release lines. Published regular support ends on May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Upgrade effort is driven by your customizations, extension count, third-party integrations and coding practices, and the Upgrade Compatibility Tool helps check compatibility. After go-live, plan a named owner, a staging environment, an automated test suite, and either an internal rota or a retainer for patching. Ask any partner how each patch cycle will be applied, tested and signed off.
What breaks most often during a Magento 1 data migration?
Extension tables and custom attributes break most often, because Magento 1 extensions frequently store data in tables that the standard mapping does not cover. Other common failures include URL keys and category paths that change, order and customer records that change after a delta run, media files missing from the copy, payment and shipping connectors still pointing at production, and cron jobs or indexers that do not run on the new server. Check the mapping for every extension table, run a delta and compare record counts and sample records, complete a full checkout against the payment sandbox, verify redirects for your highest-traffic URLs, and confirm that the cache and search services are configured. Keep a documented rollback plan for the cutover window.
How DeployOpen scopes, delivers and supports a Magento 1 migration
DeployOpen plans and runs Magento 1 to Magento Open Source migrations as fixed-scope engagements inside infrastructure you control. The work follows the Data Migration Tool path for Magento 1.6 to 1.9 stores, with written deliverables agreed before the build starts. Ongoing support is available as a retainer after cutover.
How we scope
- Inventory the Magento 1.6 to 1.9 store, its extensions, custom modules, theme and extension tables before any data moves.
- Agree in writing which settings, data sets, delta runs, table mappings and URL redirects the migration covers.
- Confirm the target Magento Open Source 2.4 release, PHP, MySQL or MariaDB, OpenSearch and hosting environment against Adobe's system requirements.
How we build
- Run the Data Migration Tool against a staging copy, then document each mapping decision and the data it produces.
- Rebuild the theme and replacement extensions as Magento 2 modules and themes that follow Adobe's documented component structure.
- Test catalog, checkout, customer accounts and admin workflows on staging, and repeat delta runs until the cutover rehearsal passes.
How we hand over
- Deliver the cutover runbook, including the final delta run, freeze window steps, rollback point and verification checklist.
- trim()
- Provide the URL redirect map, mapping documentation, custom code repository and environment configuration in your own version control.
- Walk your team through admin tasks, deployment steps and the known gaps agreed in scope before the store goes live.
How we support
- Support the store after cutover under a retainer, with fixes to migrated data, redirects and rebuilt extensions.
- Plan patch and release upgrades using Adobe's lifecycle dates and upgrade guide, since effort depends on customizations and integrations.
- Confirm with your team which support window, response expectations and change process apply before signing the written scope.
