This is the personal blog of Tasos Christidis. Evolved from a general technology blog to a cloud- and XaaS-focused resource. Special references to Software as a Service.
You can also reach me at LinkedIn: http://gr.linkedin.com/in/anastasioschristidis
Subscribe to this blog
Follow by Email
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
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?
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
Ø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,
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.
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”.
between customers and providers in the cloud business are generally governed by
the Service Level Agreement or SLA. In a previous post I made the point that a
really “tough” SLA is probably not the “holy grail” of the cloud business,
which every customer should be looking for. In this post I will continue the
same line of thought, focusing this time in the impact that a strict SLA has on
the customer organization itself. For this purpose, I will use the term “Reverse
General Data Protection Regulation
(GDPR) puts on the table a lot of new issues to be taken under consideration
and handled by all parties involved in the SaaS market; both SaaS buyers and
vendors. In this post, I’d like to focus on the vendor side and discuss a
little bit more the issue of Privacy by