Migrating Large Sites To Spree Commerce

Clarke Brunsdon and I recently spoke at SpreeConf in Washington, DC about our experiences with large scale eCommerce migrations. We have assisted several of our clients in migrating their eCommerce platform from legacy PHP based systems, to Rails-powered solutions using Spree Commerce. This is the first in a series of blogs about performing large scale migrations

Spree Commerce is an open source eCommerce platform which provides a solid platform to build highly customized advanced e-commerce sites. We really appreciate software that gives us a bunch of functionality that we need, without having to write it ourselves.

The process of migrating a large eCommerce site between two large platforms, is complicated. It's a process which will take you a long time. We say this from experience, as it's currently taking us a long time. We have made a large number of improvements to the software, and have migrated a large amount of functionality between code bases, however, there is still legacy code running, and there will be for some time. It's all part of our plan. The same type of plan that you'll need if you're looking to do a similar migration.

At the start, you'll need to do a company inventory. Understand the technology, people, and business practices that have led to where you are right now. Many decisions (both good and bad) have led to the current state, and if you want things to be different, you need to know where all the skeletons are buried. Who are the important people in your organization? Are their lone people who know the system inside and out that perform important tasks that require knowledge no one else has? Is someone connecting to the database manually fixing the problems every morning? Does anyone else know that they're doing it?

You need to ask a lot of difficult questions to make a solid transition plan. Change scares people. There are going to be stakeholders in the project who are wary that change is going to make things better. If someone's job is fixing all the stuff caused by broken software, they may be worried that they won't have a job anymore once the software is fixed. The earlier you understand people involved the project, the more you can do to mitigate human factors from what is essentially a technical migration.

As programmers, it's tempting to focus on the technical problems up front, but the problems I encounter from humans are much harder to solve than the technical ones. You need to make sure that you'll be given the support and freedom to succeed and you need to make sure that you'll be able to do it before you get fired. The decisions that you make up front are the most important of all, so make sure that they're good ones