We recently had a client that wanted to make the transition from Magento Enterprise to Magento Community to save on licensing fees, so I want to share my experience with what went into the downgrade.
A Starting Point
First things first, I needed a place to get started and where better to find that starting place than the internet? I’m not the first developer that needed to downgrade a magneto installation and after a little bit of searching I found this blog.
This was a good read to get an idea of how to approach my Magento downgrade and some pitfalls of what to look out for. It also addresses extra steps for downgrading from enterprise version of 1.13 and later, which I do not cover here.
Approaching the downgrade by treating it like an upgrade
When I broke down what I would have to do, the process actually became really straight forward. I could simply treat the downgrade like an ‘upgrade’ to community and the rest should take care of itself. All I needed to do was get the equivalent Magento Community edition and ‘upgade’ enterprise to that. Here is an over-view of the upgrade process.
- Download Magento Community. My client was running on Enterprise 184.108.40.206 so I grabbed a copy of Community 220.127.116.11
- Check for core modifications to avoid headaches later. The best way to detect these is to grab a clean copy of Magento Enterprise of the same version (if you have one) and run a diff against the clean version and the client version to see what files, if any, were changed. diff -qrbB clean_core_folder clients_core_folder
- Remove the Old Magento install. This includes the Phoenix module in Community, any related configurations and the lib folders you would find in the base Magento install.
- Assuming they haven’t been modified directly, remove all of the base templates. Keep the Enterprise templates for now though, we’ll need those later.
- Drop in the clean copy of Community.
Now that Community is in place, the next step is to either fix your templates or deal with fixing the data. At this point, it makes more sense to fix the data because it’s actually pretty straight forward and it will make your life easier when you try to view your site to see how much work will need to be done to the templates.
Removing Unwanted/Unneeded Data
The most important part of removing the data is backing up the database, because while these queries are pretty safe, the are destructive so data will be removed.
Tables that can be deleted
So, the easy bit. Just about all of the tables that start with ‘enterprise_’ (there are quite a few) can go. The only exceptions might be a table that was created by a module and they felt it necessary to start their table with the name ‘enterprise_’. These tables can be removed via a mysql admin like phpmyadmin or just through some drop table statements.
Removing the attribute data cruff
With the tables out of the way, we move into cleaning up the data itself. There are several attributes that are installed with Enterprise that have source models that require enterprise code. Since that source code doesn’t exist anymore, the attributes will need to be removed or access to the product edit screens will result in an error. Since product attributes use Magento’s EAV model, the attribute definitions are stored in one table while all of the actual data is stored in other tables. Where the table is stored is determined by the type of attribute. Looking at the attributes, the following queries should be sufficient to clean out any data that might be in Magento.
DELETE FROM catalog_product_entity_int WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.source_model LIKE 'enterprise_%'); DELETE FROM catalog_product_entity_varchar WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.source_model LIKE 'enterprise_%'); DELETE FROM catalog_product_entity_decimal WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.source_model LIKE 'enterprise_%'); DELETE FROM catalog_product_entity_int WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.backend_model LIKE 'enterprise_%'); DELETE FROM catalog_product_entity_varchar WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.backend_model LIKE 'enterprise_%'); DELETE FROM catalog_product_entity_decimal WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.backend_model LIKE 'enterprise_%'); DELETE FROM catalog_product_entity_varchar WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.attribute_code IN ('gift_wrapping_available', 'gift_wrapping_price')); DELETE FROM catalog_product_entity_decimal WHERE attribute_id IN (SELECT DISTINCT attribute_id FROM eav_attribute ea WHERE ea.attribute_code IN ('gift_wrapping_available', 'gift_wrapping_price'));
Once the data is removed, we can remove the attribute definitions and it will be like they were never there.
DELETE FROM eav_attribute WHERE source_model LIKE 'enterprise_%'; DELETE FROM eav_attribute WHERE backend_model LIKE 'enterprise_%'; DELETE FROM eav_attribute WHERE attribute_code IN ('gift_wrapping_available', 'gift_wrapping_price');
Cleaning out the old entries in core_resource
There is always the chance that a client might be re-upgrading to Enterprise at some point in the future, so it’s best to also clean out the list of installed modules from the core_resource table so that the enterprise install scripts will kick off again.
DELETE FROM `core_resource` where code like 'enterprise_%';
Templates to look out for when downgrading
After the downgrade, check to see if the client templates are based off of Enterprise. If they are, those templates will have to be moved to be based off the of Community template. Then, make sure to go through your template files and remove any files that are identical to Enterprise templates. The goal here is to only keep the files to which you have the rights. Once that is done, it’s time to go through and fix any display issues that might come up. The following are a few common places that will change when you downgrade to Community:
- Customer Registration – Enterprise gives an admin the ability to define custom attributes for a customer and, in turn, have those display on the frontend during registration for the customer to fill in without having to modify frontend templates. The good part is that those custom attributes are still defined and they will still function just as before because both Enterprise and Community use the EAV model to store customer data. However, the ability to edit those attributes in the admin is lost and getting those attributes to show up onto the frontend registration form is a manual, template editing process.
- Check the layout – The Enterprise layout uses slightly different column layouts for some pages so keep an eye on the left and right columns to see any odd issues are present and modify the template layout file accordingly to remove the columns.
- Cross/Up Sells – One nice feature in Enterprise is that an admin can define rules to associate cross-sells and upsells to products dynamically based on a rule set. That is not the case in Community and, for some reason, the templates that render the cross-sells and upsells are different. So if there are any custom template files based off of Enterprise cross-sells or upsells, they will also have to be modified.
- CMS Pages in the Top Navigation Bar – The CMS page hierarchy has one amazing feature in Enterprise that lets an admin pick pages to display in the top navigation bar along with the categories without any code changes or trickery. This does not exist in Community, so the two options are either fake it by creating a category of the same name as the CMS page and set up a redirect to point to the actual CMS page, or create a module to inject the CMS pages into the top navigation in a similar fashion as to how Enterprise accomplished it. I opted for the later. It’s not nearly as robust as the Enterprise functionality, but it gets the job done.
That should be it! At this point, the site should be completely Magento Community. As a last check, make sure to go and remove any old Enterprise licenses that are not relevant anymore and replace them with the Community licenses, where applicable.
Before I wrap up, here are a couple features only found in Enterprise that you might not think of that might be missed when you downgrade from Magento Enterprise to Magento Community.
- Multiple wish lists – This lets a customer maintain multiple wish lists. It is not something an admin would normally deal with, but you should see how many customers are actually utilizing this feature and think about finding an alternative.
- Website Restrictions – Not everyone uses this, but out of the box site restriction in Enterprise is very handy for locking down a site for private sale reasons.