Planning a Migration from Adobe Commerce to Magento Open Source

In the first post of this series, we addressed why moving from Adobe Commerce to Magento Open Source is not a downgrade but a migration to a platform that may better serve your business. With that perspective in mind, the next step is planning. The codebases are closely related, but Adobe Commerce includes modules and database structures not present in Magento Open Source. Transitioning without preparation risks breaking functionality, losing data you still need, or carrying over unnecessary complexity.

A careful plan begins with understanding what your current Adobe Commerce instance is doing today and deciding what should continue in the new environment.

Start with a Feature Audit

The most practical starting point is a review of which Adobe Commerce-exclusive features are actually in use. Common areas to evaluate include the B2B suite (company accounts, shared catalogs, requisition lists), content staging and scheduling, Visual Merchandiser, customer segmentation, advanced promotions, and gift cards or store credit.

In many implementations, these modules were enabled but rarely adopted fully. Classifying each feature as essential, lightly used, or unused will help you determine what to keep, what to replace, and what to eliminate entirely.

Map Features to the Future State

Once you know which features are in use, you can decide how to handle them in Magento Open Source. In practice, there are three paths:

• Drop modules: Remove features and their data if they provide no ongoing value.
• Replace functionality: Use third-party extensions or custom Magento development where needed.
• Adjust processes: Adapt business workflows to fit capabilities already available in Magento Open Source.

This step is where expectations are set. A company that no longer relies on Visual Merchandiser, for example, can eliminate it. A team that depends on negotiable quotes may need to source an extension or develop a custom module.

Assess Data Impact

Adobe Commerce introduces database tables that Magento Open Source does not use. If you run cleanup scripts without review, you may lose information that matters. Before migration, confirm which data can be discarded and which must be retained. For example, if you are removing the B2B suite but still need certain customer account records, those tables should not be dropped. Adjusting the cleanup scripts for your environment is often required.

Pre-Migration Checklist

Before making any technical changes, confirm you have:

• An inventory of Adobe Commerce-exclusive features in use
• A decision on which features to drop, replace, or adapt
• A list of Adobe Commerce database tables that must be preserved
• A review of third-party extensions and integrations for dependencies
• A staging environment ready for testing

Review Extensions and Integrations

Many Magento sites rely on third-party extensions or custom code. Some of these may depend on Adobe Commerce modules. During planning, identify whether any installed extensions will break when those modules are removed. Similarly, review integrations with systems such as ERP or CRM platforms to check if they rely on Adobe-specific data or functionality. Highlighting these dependencies early prevents unexpected failures later.

Build a Migration Roadmap

With features, data, and dependencies mapped, you can outline the migration itself. A roadmap typically includes:

• Finalizing feature decisions based on the audit
• Removing Adobe Commerce modules from the codebase
• Cleaning up or preserving database tables as needed
• Updating or replacing extensions tied to Adobe Commerce functionality
• Testing in a staging environment before any production changes

Where replacement modules or custom development are required, allow time for design, implementation, and QA. Treat the migration as a phased project rather than a single event.

Preparing the Team

A successful migration is not only a technical exercise. Align your internal stakeholders on what the new platform will and will not include. Developers and administrators should know how workflows will change. Customer service, sales, and marketing teams should understand how their processes may be affected. Setting expectations about scope and timelines helps avoid surprises once the new system goes live.

What’s Next

Planning is the foundation of a successful migration. A clear understanding of which features matter, which data needs to be preserved, and where dependencies exist reduces risk and prevents costly rework. In the next post, we’ll look at how to execute the migration using tools such as the Opengento scripts, and how to adapt them for your specific environment.