Migrating from one eCommerce system provider to another is probably the most stressful decisions an eCommerce Manager has to make. It comes with great risks – including long unavailability of a store or lack of opportunities for development.
The most common reasons for changing an eCommerce platform provider include:
- problems with the quality and punctuality of provided solutions,
- problems with software – expensive and long-lasting changes, lack of opportunities for development,
- problems with stability/safety of a current platform,
- the need to take software development into your own hands.
Therefore, it’s important to be prepared for complications and downtimes. To make sure the process runs as smoothly as possible here’s a checklist of things you should pay attention to while changing platforms:
- The license and access to the source code of the current platform (if you are planning on developing it further).
- The plan of modification – which includes gathering all the requirements, implementing the new version and ensuring its quality.
- Ensuring the business continuity.
- Ensuring the system acquisition plan.
- Hosting issues.
Depending on whether you want to acquire the current platform (but part with the current provider) or you plan to transfer the store to a completely different platform – it’s necessary to keep various aspects protected:
License of eCommerce platform
In case you decide to part with your current provider but acquire the software development, you need to address license issues. If the software has an open source code (e.g. OSL2 licenses – Magento, BSD and others), acquiring the code shouldn’t be a problem.
However, commercial licenses may sometimes come with additional cost such as acquiring the “developer license”, which allows you to develop the software on your own.
In rare cases, with some SaaS platforms for example, it may be impossible to migrate to another platform. Then, the only solution is to rewrite platform as a whole.
Developing a new eCommerce platform
If your current platform has considerable disadvantages such as security issues, efficiency issues or the architecture just lacks development capabilities, then the best solution may be to change platforms.
In this case, you should decide to start a new platform – along with collecting all the requirements, establishing the duration of development, testing, and launching.
At the analytics stage you can use the current version of the store acting as a “proof of concept” – writing down requirements based on current screens or even using screenshots.
It’s more convenient if you can transfer the working software without major modifications. However, do so with care, so that at the end of work you don’t realize that certain functions have been forgotten or don’t work the way they should. That’s why an analyst is necessary in this process.
Of course, it’s also necessary to make sure that the new platform actually solves the problems you had. If these were functional problems, look at detailed documentation, prepare a functional design of the new system and verify it with users.
It’s also worth using a checklist – e.g. either the one we have prepared or looking at more from DropShipLifestyle.com. Make sure your including the points to keep in mind when testing and deploying the new platform.
Changing eCommerce Platform Checklist
Continuity
Operational continuity is key – without ensured continuity your company may suffer financial losses. You need to minimize downtime but also assume that a few hours break may be required.
The whole process also requires time for migrating all users and data, final testing and deploying the platform.
It’s vital to keep the previous version online as long as possible. You need to ensure it’s maintained and hosted until the new platform is ready to launch.
Another important aspect is determining the plan for the data transfer (data dumps). Transferring can be very time consuming, so it’s an important thing to keep in mind.
Therefore, it’s important to establish a transfer plan and write it in the form comprehensive to all 3 sides (the old provider, the company, the new provider) with dates and specific times of conducting the steps.
Hosting
Hosting is another important aspect to keep in mind when switching providers. In most cases the current software provider is also the hosting provider. That’s why, it’s best if your new provider can provide you with the full package of operations, along with servers and administration. If there’s no such possibility the person overseeing the whole migration process has to remember about changing the server platform, signing appropriate agreements and synchronizing deadlines in advance.
How to prepare for changing providers
The technology provider should be able to develop your system in a way that will protect you from vendor lock-ins. It’s your responsibility to ensure you avoid any such complications.
All communications related to the project should be stored in a tracking program (e.g. JIRA) and the source code should be stored in a version control system (e.g. GIT). Of course, along with comments about subsequent changes. Order during software development process is what facilitates the transfer of applications. You can and should require order when commissioning the development of an application.
Documentation
Clear documentation of the migration process is probably the most crucial aspect. The company in charge of migrating the software should include the software documentation – which is an IT requirement.
Without such documentation, your team will have to analyze the source code and make random changes without any certainty about the operations of the modified mechanisms.
Such documentation doesn’t need to be particularly long. If during the analytical phase (pre-implementation) documentation was kept properly, then it can constitute as a foundation for software documentation.
In case you haven’t agreed on clear terms of documentation then your provided may charge extra for the documentation. Creating descriptions takes time, but it’s worth it. Since abandoning this step may involve too many risks.
To help you make sure you have everything you need in the documentation here is a general checklist:
- Characteristics of the application architecture – module division description, module purpose, or their dependencies.
- Description of non-trivial algorithms – e.g. mechanisms for calculating price should be accurately described, as well as mechanisms for retrieving data from external systems. In short, the algorithms with atypical effect or those which were changed.
- Description of procedures for installing and launching the system and description of what and when should be cleaned in the database. Which logs should be rotated, how to create backups – typical maintenance activities will be needed from the beginning and not knowing them can lead to a system failure.
- Description of other activities that must be performed for the application to run.
- Description of the most important classes and layers – a typical developer’s description that will facilitate finding a place in the code to introduce changes or to fix a bug.
- Description of database structure – with complex relational databases in addition to describing the tables, it’s also necessary to describe dependencies (relations). Sometimes it only takes a simple ERD (Entity Relationship Diagram) with a comment about the purpose of each of the tables. Usually it’s pointless to describe each column in the table, as their purpose is often self-explanatory. If it’s not, you can always ask for a detailed explanation,
- Troubleshooting description – if there are common emergencies and procedures for their occurrence, it’s necessary for documentation to include their detailed description.
Documentation should be accepted by the team that will deal with further maintenance of the application – they are the ones that need it. The team should have at least a few days to analyze the material and submit their possible observations. Remember that creating documentation isn’t a pleasant duty for developers and often effects of their work leave a lot of room for improvement – descriptions are brief or key mechanisms are not described.
Undeniably, the process of migrating your eCommerce platform may be exhausting and troublesome however, all the hard work should pay off with a great new platform functioning just the way you want it to. Just remember there are lot of aspects to overlook during the migration, so don’t be careless!
Published November 2, 2015
