The CLI tool we built internally to handle Adobe Commerce to Magento Open Source migrations is now available on GitHub under MIT license. Here's why we built it and what it does.

When you've done enough Adobe Commerce to Open Source migrations, you start building tooling. What begins as a collection of SQL scripts and manual checklists eventually becomes something more structured. That's what happened here.
Today we're releasing the tool we've been using internally: Magento 2 EE to Community Tool. It's a CLI utility that handles the technical heavy lifting of converting an Adobe Commerce installation to Magento Open Source.
We've written before about the business reasons merchants move from Adobe Commerce to Open Source — licensing costs, unused features, wanting to escape the push toward black-box SaaS services. But the business decision is the easy part. The technical reality is messier.
Adobe Commerce introduces structural differences that make a straight swap impossible. The most significant is how Commerce handles core entities. Products, categories, CMS pages and blocks all use a row_id primary key system rather than the standard entity_id approach. There are also around 90 additional database tables, staging sequences, and schema differences that Open Source simply doesn't expect to find.
Manually unpicking all of this is slow, error-prone, and honestly a bit nerve-wracking. One wrong step in a SQL script and you've corrupted your product catalogue. We needed something repeatable.
The migration runs in three phases:
Database migration is where the real work happens. The tool removes Commerce-specific tables, rewrites the primary key structure to convert row_id references back to entity_id, and aligns the schema with what Open Source expects. This is the part that's genuinely dangerous to do by hand — it touches the core entity tables that hold your products, categories, and CMS content.
Composer migration updates your composer.json, swapping out the Commerce metapackage for the Open Source equivalent and flagging any Commerce-dependent packages that need attention.
Verification compares the database state before and after migration, checking that no Commerce tables remain, no row_id columns are left behind, and that row counts look sensible. It's a sanity check before you proceed with the standard Magento upgrade steps.
We're releasing this because we think it's useful, but we're not pretending it's risk-free. The tool makes irreversible changes to your database and project files. You need proper backups before running it. You need to understand what you're doing.
This isn't a one-click solution for someone who's never seen a Magento database. It's tooling for experienced engineers who want a structured, repeatable process instead of manual SQL and crossed fingers.
Migration between Magento editions has always been tribal knowledge — undocumented SQL scripts, war stories shared at conferences, agencies guarding their internal processes. That's not helpful for anyone.
We think tooling like this should be transparent and reviewable. If there's a better way to handle a particular table conversion, someone in the community will spot it. If there's an edge case we haven't hit, someone will file an issue. The tool gets better, and everyone benefits.
It's MIT licensed. Use it, fork it, improve it.
The tool is freely available, but the decision to migrate isn't one to take lightly. It's a significant technical and commercial choice.
If you're evaluating whether Open Source makes sense for your business, we offer a Migration Audit that gives you a clear picture of scope, timeline, and challenges. If you've already decided to proceed and want experienced engineers handling the migration, we can help with that too.
Either way, the tool is on GitHub. Take a look, read the code, and if it's useful to you, let us know.