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.
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.
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:
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.
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.
Before making any technical changes, confirm you have:
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.
With features, data, and dependencies mapped, you can outline the migration itself. A roadmap typically includes:
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.
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.
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.