Magento

How to Downgrade from Magento Enterprise to Magento Community

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.

  1. Download Magento Community. My client was running on Enterprise 1.12.0.0 so I grabbed a copy of Community 1.7.0.2
  2. 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
  3. 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.
  4. 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.
  5. 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.

Once the data is removed, we can remove the attribute definitions and it will be like they were never there.

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.

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.
Jarod Rose

Written by Jarod Rose

A Certified Magento Developer, Jarod not only provides our clients with great Magento solutions for their businesses, but he also leads Envalo’s Magento Training and Certification Program for developers. Besides Magento, Jarod has experience with jBoss, GWT, Java EE, Seam, PHP, Ant, Maven and WebSphere Commerce. He holds a Master’s in Computer Science from the University of Akron. He is Envalo's Director of Development.

  • Mark Winkler

    Thanks for the info. How much time should one allow (before the expiration of Enterprise membership) to make this transition?

    • Jarod Rose

      I think the downgrade that inspired this blog over the course of a week. Then we had a week or so with UAT with the client. It all depends on how many modules you have installed and how much testing you’re willing to do make sure everything is stable on community. I’d say a safe number on average is around a month, but you can probably get away with less.

  • Nicholas Zucker

    Thanks for the detailed and informative details.
    One quick question, why do you need to match the EE version to the CE version, why couldn’t you just use the latest CE version available? I’m not asking about Magento2 but about 1.9.

    • Jarod Rose

      You very well could, I went this route because it limits the number of differences I had to deal with during the downgrade to just the enterprise related ones, especially for older versions of EE. So during troubleshooting I didn’t have to worry about version number incompatibilities with modules, they just needed to support community.

      • Nicholas Zucker

        Thanks!
        How can I get a quote from you?

        • MichaelMoores

          Nicholas, Fill out our contact us form (http://www.envalo.com/contact/) with contact information and I will reach out to you in the next day or two!