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.

Step 1: Perform a detailed assessment of your current environment.

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:

1. Is the extension you installed on CE required on EE or does EE offer similar functionality out of the box? For elements like coupons, pricing promotions, loyalty points, the answer is likely yes.  As a result, you will likely not carry the extensions over to the new site, but you will probably need some form of data migration to move the data from the extension’s table structures into the out of the box Enterprise Edition instances.
2. If the extension is not duplicated by out of the box EE functionality, is there an EE version available you can use?  Note, many extensions used on community edition are not supported on Enterprise Edition at all. In some cases, an EE version may exist, but you need to purchase a different version or license key and apply a new package that is compatible with EE.
   1. If you are going to be implementing an EE version of an extension, make sure the provider has documentation or can walk you through how to upgrade your CE version to EE version.
   2. If the extension is not duplicated by out of the box Magento EE functionality, and an EE version of the extension does not exist, you will need a plan and timeline to either update the extension’s code to work with EE or replace it with a custom built set of logic or functionality.

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.

Step 2: Check for Core file changes

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.

Step 3: Plan for test and deployment

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.

Step 4: Execute the upgrade

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.

Step 5: Test, Validate, Revise

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.

Step 6: Plan for Go Live

To convert your in production site to EE, you’ll need to do one of two things:

1. Either plan for some minor downtime on the site (and have a site down for maintenance notice page in place ready to go) <or>
2. Stage a parallel EE Production site with the completed/ upgraded software in place and plan to cut over from one box to the other, realizing you may have a few straggling orders in the old site that either don’t show in the new site or need to be migrated over via a data migration.

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.

Step 7: Plan for “Post Deployment” Support – you need a plan in place before you launch your live site

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.

In this review, you will learn how and why the SugarCRM Web Services Platform is a reliable, scalable, and cost-effective method of integrating to your SugarCRM application, regardless of the selection of an On-Demand or On-Premise infrastructure.

The flexibility of SugarCRM’s Web Services allows you to choose the integration programming models, languages, and operating systems that you are already using or that are best suited for your project. With SugarWS, you can bring your existing skills and knowledge to the platform; you don’t have to learn lots of new skills.

SugarCRM dramatically reduces the effort to integrate with either on-premises applications including Microsoft, Oracle, SAP, or other third-party solutions and external cloud services such as Amazon Web Services, Facebook, Google AppEngine, and Twitter. A large percentage of the traffic in SugarCRM’s On-Demand infrastructure is system-to-system integration, showing that it is a trusted and successful enterprise API that is used globally by SugarCRM clients worldwide.

SugarCRM Web Services

SugarWS provides a number of paths to integration success—all based on our industry-leading Web services API. Integration with SugarWS means faster, simpler, and less-risky integration that doesn’t break during upgrades and delivers a new level of access and agility to your existing IT investments. SugarWS is designed to work with all major integration middleware solutions, and for building custom integrations plus maximum flexibility and choice, the SugarWS platform supports all major development environments and tools, including .NET, Java, PHP, Ruby on Rails, and many more.

Besides a robust SOAP interface with a revamped list of available calls, SugarWS introduced major updates to the framework in 2009 such as Versioning and Extensibility, and the addition of a new REST interface.

Prior to 2009, the SugarCRM web services API had a wide variety of calls allowing you to get at almost any piece of data in the system. One downside of the diversity of calls, was that accomplishing certain tasks via the API could be burdensome in that while flexible, an integration might require multiple calls to complete a task (traversing and retrieving the details of related items is one such example). In 2009 SugarCRM rewrote all of the API calls. Based on the improvements to the framework, SugarCRM was able to reduce the number of calls down to 20 by allowing for the passing of extra parameters in to certain calls and eliminate the number of round trips to the server.

Call Description
login() Logs the user into the Sugar application and create a session
logout() Logs out the user and ends the current session
seamless_login() Used for Sugar Offline Client or to accomplish single sign on
get_user_id() Returns the user_id of the user who is logged into the current session
get_entry() Retrieves a single record with details based on the ID
get_entries() Retrieves multiple records based on IDs. This API is not applicable to the Reports module.

get_entry_list() Retrieves a list of records for a given module
get_relationship() Retrieves a collection of module records that are related to a target record and optionally return relationship data for the related beans.
get_note_attachment() Retrieves an attachment from a note
get_document_revision() Allows an authenticated user with the appropriate permission to download a document.
set_entry() Creates or updates a single module record
set_entries() Creates or updates a list of module records
set_relationship() Sets a single relationship between two records where they are related by module name and ID.
set_relationships() Sets multiple relationships between two records where they are related by module name and ID
set_note_attachment() Adds or replaces an attachment to a note
set_document_revision() Sets a new revision to the document
search_by_module() Returns the ID, module_name, and fields for the specified modules as specified in the search string.
get_server_info() Obtains server information such as version and GMT time
get_module_fields() Retrieves the vardef information on fields of the specified module

SOAP is probably the most used web services protocol. It provides a way of exchanging structured information of application functionality. A SOAP interface can be defined by its WSDL (Web Service Description Language) file. To access the WSDL for Sugar Web Services API you can read it by going to this URL in your browser: http://sugar_root_url/service/v2/soap.php?wsdl. The WSDL file will give complete explanation of all the methods with input/output data type.

Sugar Web Services also supports a robust REST interface. This adds a lightweight integration to gain access to data in a system. REST is preferable for higher transactional web integrations, as well as browser client side implementations where all rendering happens in the browser. To connect to the REST interface in the new web services framework you will connect to the following URL: http://your_sugar_url/service/v2/rest.php.

Widely Available Web Service “Stubs” from SugarExchange – notable examples

The following integration sets are readily available from SugarExchange. These allow for communication to/from SugarCRM, and make use of the SugarWS for integration purposes. This is NOT an exhaustive list:

• QuickBooks Real-time Integration
• Adobe Echo Sign Integration
• Authorize.Net Integrations
• BonitaSoft Workflow Integration
• Contivio Integration for Telephony
• eXo Plug-in for SugarCRM
• IBM Websphere CastIron
  • Salesforce.com
  • Oracle Applications
  • SAP
  • Oracle CRM
  • Amazon
  • Chatter
  • Microsoft Dynamics
  • Eloqua
  • PROS
  • SignalDemand
  • Zuora
  • Google Apps
  • NetSuite
  • RightNow
  • Teleo
  • SPS Commerce
• iZeno Integration
• JigSaw Integration
• ProcessMaker API
• Sage MAS90 Integration
• Talend Integration
• Velaro Chat Integration

Example Scenarios of Web Service Use

Summary

Web services create compatibility and interoperability among various packaged and customized Web applications – in a standardized and vendor-neutral manner. Web services are most economical – and beneficial – when used in an enterprise-level business scenario that combines the functionality of multiple applications into easy-to-use enterprise services. Such a business scenario requires a service-oriented architectural approach.

For SugarCRM, Web services play an important role in the concept of enterprise service-oriented architecture (enterprise SOA). Web services ensure interoperability between platforms, and all communication within enterprise SOA is based on Web services. Enterprise services expose the functionality and data of applications so that they can be accessed by any service user. Just as Web services take the complexity out of platform connectivity, enterprise services take the complexity out of application integration