Downgrading Adobe Commerce to Magento Open Source

Downgrading Adobe Commerce to Magento Open Source

Find eCommerce developersFind eCommerce developers
Find eCommerce developersFind eCommerce developers
Find eCommerce developersFind eCommerce developers

Introduction

If you've been keeping up with recent conversations which were sparked by the Adobe developers conference in February, one of the questions you might be asking yourself is, can I downgrade my Adobe Commerce store to Magento Open Source?

The new direction Adobe is taking Commerce with an increasing amount of functionality moving to SaaS services is certainly not going to be for everyone, and you might even be feeling Magento's future is unclear enough at this stage to be thinking about migrating to another eCommerce framework altogether.

However, the future of Magento Open Source is perhaps now looking more certain than Adobe Commerce, in terms of the framework and functionality as we currently know it.  So if you want to make sure you keep that level of customisation that comes with Magento, and don't want to potentially be forced into using less customisable SaaS functionality, then downgrading from Adobe Commerce to Magento Open Source could be a good option for you.

The downgrade

So what gives me any level of authority to talk about the complex development task of downgrading Adobe Commerce to Magento Open Source?

Well, I'm a Magento developer myself, and I've been developing Magento profressionally since 2010 starting as far back as Magento CE 1.3.  I've extensively developed both paid and free versions of Magento 1 and 2, and I've personally performed a Commerce to Open Source downgrade for one of my clients.  Here I built the downgrade process right from initial research and testing, to preparing a fully custom, documented downgrade process, to countless hours of testing in staging and local environments to confirm the process works ahead of time, to actually performing the downgrade on the production system.

The install I downgraded has been operating as Open Source without issue for many months now, and I know that the process I created can be applied to any Adobe Commerce store and that's why I wanted to share my findings with you today.

Downgrade preparation

The first thing I did was review and test all the information I could find about downgrading Commerce to Open Source that already existed.

There's a few different guides out there, and they're noted in the documentation I produced, but I found there was primarily one key area that was missing from all of them - and that was the fact that there are considerable differences between the database structure of Commerce and Open Source.  This meant none of the guides were any good for a store with existing data.

So I went through and tested all of these existing solutions, but the end result was a completely broken Open Source store at the end.  Downgrading the codebase is really the easy part, its the changes to the database that make it a difficult task, and these guides largely only covered downgrading the codebase.

Of course it's easy to upgrade from Open Source to Commerce, but Adobe are never going to make it easy going the other way, and that might be why these database changes exist.

Custom downgrade solution

At this point it was clear that we were going to need a completely custom downgrade process so I started a full analysis of the actual requirements, and documented it all as I went.  What I found was that downgrading the Magento core codebase was simple with composer, but there were challenges around:

  • Existing third and first party extensions - would they be fully compatible with Open Source or was there any Commerce dependency
  • Replacing Commerce only functionality with third party Open Source compatible extensions - how to migrate existing Commerce database tables data and have it work with a third party extension
  • A multitude of fundamental database differences between Commerce and Open Source

Existing third and first party extensions

Here I had to consider how existing third and first party extensions worked, primarily thinking about any functionality which related to, or required Commerce only data or classes, and make updates based on that analysis.

Replacing Commerce functionality

After research, the main areas for consideration for my client were the companies, and returns functionality offered by Commerce.  In this case replacement Amasty modules were decided on because the functionality was good, plus the structure of the database tables the modules added were close to the Commerce equivalent, particularly with companies where the tables were near identical - and this made data migration easier.

Fundamental database differences

I went through the databases for Commerce and Open Source with a fine tooth comb, table by table to determine all differences, which as you can imagine took quite some time. The main differences it revealed were that quite a few tables had a different name for the primary key column, and thats the main way in which each record in the table is referenced by Magento - according to the entry in this column. I also found significant differences around foreign keys which are used to define a link between different database tables.

The approach

The only way to ensure success in downgrading was to very throroughly collate all my findings into a solid plan containing both the code changes and the database changes that were needed.  The end goal was to have an Open Source install with all traces of Commerce completely removed so Adobe couldn't argue the install still needed a Commerce license.  I documented it all throughly producing a document of around 130 pages, commited the needed code changes ahead of time into a downgrade branch of the repository, and produced all the SQL scripts needed to downgrade the database as transactions so if something did go wrong the database changes wouldn't be partially applied which would break the downgrade process.

After that it was just a case of test, test and test again with dummy data in local and staging environments.

When it came to the actual downgrade of production, everything was backed up just in case a rollback was needed, and then I performed the downgrade.  Thankfully due to the amount of preparation that went into the process the downgrade went smoothly and many months later the store is still running without issue on Open Source.

Downgrading your store

If you want to downgrade your store from Adobe Commerce to Magento Open Source, I've proven it can be done.  However to complete the highly complex process of downgrading successfully does require close attention to detail from a competent and experienced developer.

To give you a massive head start, I've made the documentation and database scripts I created available to all and you can find them here.

It's important however to note that you probably won't just be able to apply exactly what I've done to your store - it will get you 95% of the way there, but the key thing to do is test thoroughly, and then customise as needed before any downgrade is performed on a production install.

If you'd like to have a conversation about me performing the downgrade for you given my experience of already having down it before, drop me a message using our contact form and I'll be sure to pick it up.

Or if you want to use one of the highly competent developers who list with us at Developer Connection to perform your downgrade, you can create a project in a few minutes with a couple of clicks.

Find eCommerce developersFind eCommerce developers
Find eCommerce developersFind eCommerce developers
Find eCommerce developersFind eCommerce developers