With the recent feature rich releases of Magento Enterprise, there has been a groundswell of Magento customers that are shifting from Community to Enterprise.
In Magento’s early days – the gap between the community and enterprise products was narrow…but that is no longer the case. New features, improved architecture, multi-storefront approaches, PCI, scale, speed – these are all areas that Magento has invested heavily in their Enterprise solution.
A large volume of merchants who have successfully grown their existing ecommerce business using Magento’s Community Edition have been confronted with the the need to improve their system scalability and features. as their online traffic increases.
In short, companies are quickly outgrowing the Community Edition. Many Community edition users have been painfuly confronted with the realization that trying to customize Magento Community Edition to try to mimic enterprise through custom code and the use extensions doesn’t really save money over time and can in fact cost more.
So…for all of you looking to make the Community to Enterprise move…here’s how to do it.
In this review, we will share some of the key items to consider when planning for your upgrade and what to expect when executing your upgrade project.
Upgrading to Magento Enterprise from Community Edition does not have to be a difficult process. But to do this in a predictable, reliable manner, there are some very important facts you need to know before you start.
First, what version of Community Edition (CE) are you using? If you are using version 1.5.0 or earlier, your upgrade is going to be more difficult. Architectural updates to the platforms beginning with the release of version 1.5.1 of CE will result in a multi-step upgrading process to resolve differences in the software stack. If you are working with a partner to do this upgrade, make sure you provide this information and make sure you provider can provide you with a game plan of what to expect.
Second, identify and document which extensions or plug-ins you have installed on your CE instance. For each extension installed, you’ll need to answer the following questions:
For step 1, plan on spending a day to catalog your extensions and at least one to two days reviewing the alternative solutions and building your plan to address items 1, 2 and 3.
Once you have cataloged your extensions lists and defined your areas of impact, the next thing you need to consider is whether you have made changes to the core Magento files (non upgrade safe changes). Note, Magento’s architecture has a defined method for applying changes in an upgrade safe. Your IT team member or services partner may want to consider taking a copy of your site, and a clean, unmodified version of Magento CE that you are using and do a ‘diff’ on the core file structures to see what has been changed, if anything.
If you have made core file changes, note, you will want to take a full back up of the changed files because there is a strong likelihood that the upgrade will overwrite some of these changes, if not all.
Make sure you comment the sections of code where you identified core changes.
*A note on integration work. Integrations are typically done in an upgrade safe way. However, you want to pay special attention at this point to document and backup any files you used to integrate Magento to any other system. These will be critical points of verification as you move forward.
Once the changes have been documented and backed up, move on to step 3.
Start with the end in mind, plan for testing and deployment before you start your upgrade project work.
You don’t want to upgrade your production instance right away. In fact, you may not want totally upgrade your production instance at all, you may want the two instances running side by side for a time to give you a fallback option is something goes wrong.
So first, plan on how you will deploy your upgrade to production and where you will do you upgrade project and testing prior to launch. We strongly recommend you setup a development site and server. This means having a separate physical host (or virtual server) that will not share resources with your production server. The upgrade process can be resource intensive – you don’t want to disrupt any production activity during this project.
Once you have your development / test server in place, take a full back up of your production site (code and database). Deploy it to your development server, and keep a copy of the backup zipped up for reapplication if you need it. You don’t want to have to take multiple backups if you run into issues early on in the process.
With the development site in place, you’re now ready to plan for your acceptance testing.
It is a great practice to document your testing steps and expected results (an Excel Spreadsheet is fine) before you start work. Take screen shots so you can compare before and after results to make sure your logic changes work the same after the upgrade. Make sure you define all the key conditions you need to validate before you launch to production.
Also, make sure you test scripts include a means of validating that any integration interfaces you had in place still work properly. Integration is usually time consuming, and you don’t want to realize after you’ve deployed to production that you need to update this portion of your site post go live.
Trying to put this together after you’ve done your upgrade can be very difficult – so start with the end in mind.
Time to upgrade.
Based on your assessments in steps 1 and 2, you should begin applying the upgrade package and working through your plan for extension or core file change management.
If you are starting with version 1.5.1, the upgrade to the current version will be relatively quick (a day of effort to run through and do an initial validation of results) and painless. Reapplying extensions, core file changes or new logic will then occur and the effort for that will depend on the volume of changes you have to support. If you don’t have many extensions or any core file changes, this part may take as little as a few days.
If you have a large number of extensions, core file changes, etc, you could spend a few weeks going through this process.
**Note, critical success factor for managing time, budget and success.
We strong urge that customers NOT begin adding new functionality or features right away or as part of the upgrade process. Moving to Magento Enterprise Edition will arm you with an entire new set of features and tools. You should strongly consider releasing the upgraded site first, let it bake in, learn about what you now have at your disposal, and then plan on what new features and functionality you want to add after your new site is in production and you are comfortable that everything is stable.
You will learn that Magento EE does more than you think. You’ll also learn that the approaches to adding new functionality change with EE and it is a much more flexible architecture. – A little patience on this front will save you time and money overall.
Once you have what you consider to be an upgraded development instance, it’s time to execute your test plan. Go through and test with detail that the upgraded development site functions substantially the same as what you previously documented. Validate not only that it is error free, but that calculations, taxes, UI elements, etc. all match up. Be sure to test any integration interfaces you had in place and that integration transactions work properly. Finally, make sure that any extensions you replaced, upgraded or removed work properly or that the intended revised functionality based on EE out of the box tools works as you expect it to.
When you can confidently say you have validated your existing, as is functionality is working properly, you are ready to plan for a move to EE in production.
To convert your in production site to EE, you’ll need to do one of two things:
When you do this, the biggest thing to realize is that if you are making DNS changes to point to a new host, those changes may take up to 24 hours to propagate nationwide or worldwide.
As a result, it’s a good idea in advance of your launch (at least 3 or 4 days in advance) to reduce the Time to Live (TTL) settings on your DNS entries to as low a value as possible so that the changes propagate as quickly as possible.
Even with a low TTL, some traffic will still route to the old IP address for a little while unless you’re firewall or network configuration has a rule in place to route to the new host internally.
Either way, plan to make the production move at the beginning of what is a low traffic period for you. Most people automatically assume this means weekends. For B2B oriented sites, that might be the case. But realistically, you should look at which days of the week (and times of day) have the lowest volume. It very well may be that a weekday in the morning is the best time to make the change.
When you plan your cutover, make sure that all necessary support, admin and customer service representatives are aware of the change so that if call volume to your office increases, they can give a clear message and that they are prepared for any spikes in activity.
This is the one area that is constantly overlooked or undervalued. When you make any large change, you will find that something comes up post launch that you either didn’t anticipate or that you missed somewhere in your process.
If you are launching in off or late hours, your support staff will need to be calibrated to provide late hours support and probably be in early the next day in the event there is an issue to triage.
If you running a site with high volumes of traffic or orders, you, your support staff, and your IT team or partner need to have a plan in place for ongoing bursts of activity for at least the first week post launch.
Once you get through week 1 and all is calm, then it’s time to prepare for the next batch of new functionality you wish to implement.
Disclaimer: The company I work for is partners with several vendors