This question was asked by an attendee during the Proformative
A video of this webinar can be viewed here: https://www.proformative.com/resources/webinar-video-
How do you deal with switching among cloud vendors if you want to make a change down the road (or if you are forced to change for some reason)? (Webinar Attendee Question)
Answers
There was similar question here related to converting from the cloud to an on-premises based system. http://goo.gl/SBU4a Either way, you are looking at a conversion from one system to another and need to decide how much history, detail and master record data you will bring over. One thing that shouldn't be underestimated is that you aren't just changing apps, you are changing platforms - whether it is a move to another cloud or on premises. This means you will have changes to logins, reporting tools, workflow tools, customization tools, social media apps etc. It is not just an app change, it is a computing environment, ecosystem and skill-set change. One nice thing about the cloud is that subscriptions can run short term, say yearly. So if you change, you can get out before you've invested tons of money in servers and paying upfront for a perpetual licenses that will take many years to write off.
We had to do that b/c we just couldn't get the CRM functionality we wanted out of our existing cloud integrated ERP/CRM system and thus switched from that to salesforce.com. Happily, our original cloud CRM provider had reasonably easy import/export functionality and with the help of their support folks we made the transition easily from a systems perspective. What was not so easy was the data cleanup involved. That had nothing at all to do with the systems, but had everything to do with "data hygiene" - or lack thereof. I find that as any system gets significant use, some of the data gets dirty. in the case of CRM, it was having old sales reps assigned to the wrong customer account, old customer contact data in the system, etc.. We took the changeover as an opportunity to clean things up. That's what took the time and effort.
However, i have often thought about what would happen if a cloud vendor went belly up (Chapter 7 or 11) and i think on that front you have to be very familiar with the financial state of your cloud providers. I'm not so sure I'd receive lots of notice from a provider that was having liquidity problems! This is a clear
I agree with Bryan on the utmost importance of financial consideration when looking at an eventual on-premises migration.
Technically, this type of migration (otherwise called data conversion) can be a pretty daunting task if either the legacy export or the new-system import functionality are not flexible enough. As a former project manager, I have seen horrendous approaches to it because the legacy system was not fully known (especially in the case of SaaS or cloud system where the consulting services are not, per nature, as developed and knowleadgeable as on-premises' ones) or because the new repository requirements were not fully assessed.
I always advise to have your whole migration scope fully figured out (including before/after tests) before you take on the project.
One of the recognised weaknesses of Saas-only and Cloud vendors is the ownership of data, a by-product of the multi-tenancy. Always ensure that embedded import/export functionality are up to scratch because they'll be your only way out in case you need to switch.
On a brighter side, except for the youngest companies and depending on the industry, the most reliable vendors will be able to propose you a system migration from cloud to on-premises. This is at least the case in the
Checking the origin of the cloud (whether working directly with a cloud provider such as Microsoft, IBM, Rackspace, Google, etc. or sub-letting it) is another key check in case of forced migration as data conditioning (are you allowed to contact the cloud host directly to ask for extract?) can be different from one provider to another. At IT2, we are open about our Cloud offering, using Microsoft Azure as provider but allowing a seamless migration (database copy) from one deployment option to another. A few ERP will allow to do that as well.
Filed Under:
Technology