Data migration to SaaS

In the organization’s journey from an on-premise Business Application setup to a Software as a Service one, one of the key factors of success is data migration. Of course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution for my case?”, “Does it address my special requirements?”, “am I content with the reporting/BI capabilities that it offers?” etc. But having answered all of the above, you should take into consideration the data migration issue.

This post will point out some very significant issues around this subject, which you need to address and examine; probably in close co-operation with the SaaS vendor of your choice, before accepting their financial proposal and start the journey.

You might ask, why I am focusing the migration issue to SaaS. Aren’t there always the same questions that must be answered and the same fears that need to be relaxed, regardless of whether we are discussing a new on-premise or in-the-cloud installation? The answer is that there are many cases where SaaS implementations are run like a typical low-cost, semi-automatic on-boarding process, where the vendor may not even be present (or in the same geographical location as you are), instead of a typical “waterfall” type of project where the migration process is a distinct sub-step of the project, it has costs and time associated with it and new code is most likely to be written by both sides. Therefore, in order to succeed in such a low-cost, fast-on-boarding, “mini” project, customers must have a clear vision of what they want to transfer and vendors, from their side, must be certain that they can accommodate these needs with little or no customization.

• What kind of data do you wish to move to the new platform?

From all the data sets that you are managing and working with every day, it is very probable that there are some that you don’t really need to migrate to the new platform. There may be pieces of information that exist simply because they were generated or required by the legacy application. For example, could it be that a purchase order was necessary in order to book a vendor’s purchase invoice, while your purchasing process isn’t quite as sophisticated? In that case would you really need to transfer these purchase orders to the new SaaS application?

Another example is that of data with a limited useful life. For example, if you don’t actually have CRM functions in place, then you’d probably not need those old closed Sales Orders that have been invoiced to your customers. If you really need to look at their purchasing habits you could look directly into the invoices database, hence rendering the Sales Orders database unnecessary.

It is very important to answer this question beforehand, because although I can imagine that all systems provide some functionality to upload, say, Customer and SKU records, I am not sure whether they all offer out-of-the-box functionality to upload all the kinds of ERP or CRM kind of transactions that you may require.

• What is the depth of the data that will be moved to the new platform?

After having answered the above question, then you need to decide the depth (history) of the data that you will transfer.

The obvious answer in a perfect world would be “everything”. Move, for example, all detailed transactions from the past in the new platform so that the full history of your business events is available on it. The old system will fade out in a second.

But is this achievable? To answer this question you must answer to yourself whether there is adequate knowledge in your organization of the legacy databases that you are moving to the cloud. If not, where can you find and employ external contractors (or the original software vendor) to assist in that task? And how expensive will this be?

Also, will transferring a large amount of legacy data have an impact on the monthly SaaS fee (that is, if your vendor’s pricing scheme includes volume-based pricing)?

An alternative could be to only transfer “some” data, not the entire history of your business transactions. For example, leave transaction history of customers in the old system and start the new one with just beginning balances. In that case the migration task becomes so much easier but you need to answer a new set of questions: Is it acceptable by the Business to have to go back to the old system to look at history details? What will be the cost of keeping the legacy system up and running for many years in the future (and how many is “many”)? Is it acceptable to not have the entire history of the Customer in one transaction ledger and how is it going to affect daily business and customer relations?

• Migration technicalities

After having decided what kind of data you will transfer and how “deep” their history will be, you need to clearly define the migration tools and methodology that the SaaS vendor will use. If there are specific technical implications that need to be addressed from your side, you should be aware beforehand. For example:

Ø  If there is a need for an additional tool/middleware that must be deployed,

Ø  If the migration will be achieved via files exported from the legacy system and whether you are able to produce them (or you need the assistance of a third party) or there is some other kind of technology that your SaaS vendor suggests,

Ø  An evaluation of the size to be transferred and whether it can be automatic and unsupervised and can fit in an afternoon of off-hours or it needs a weekend of efforts,

Ø  Etc.

Most SaaS vendors will offer out-of-the-box functionality to execute the migration. Is that tool set and methodology enough for your specific needs?

If we look at the issue from the SaaS vendor’s side, then vendors should have a clear methodology and tools for the migration process. In the SaaS world, it is theoretically very easy to on-board and disembark cloud services. What is not easy to do is handle failed migrations not because the application is not good enough but because the data migration issue was not addressed correctly.

What SaaS vendors can do is equip their systems with easy-to-run-and-customize importing tools, so that they can do their part of the job easily and with low risk. Obviously, the old rule of “garbage in, garbage out” still stands, no matter how far applications and systems have gone since the 1970’s (!) but at least SaaS vendors must do all they can to address the issue and, at the end of the day, protect their reputation as “trustworthy partners”.