Moving to Cloud-Based Services

Cloud services offer infrastructure without administration, predictable costs and lower capital risk. But getting to that promised land from your island of in-sourced headaches involves overcoming three hurdles: moving live data from inside your infrastructure up into the cloud, convincing everyone with security concerns that everything’s going to be alright, and coming up with a smooth transition plan that minimizes downtime.

Your previously internal data will have to be migrated into a cloud service. The effort to do this varies depending on the service that you’re migrating. For instance, are you moving all of your sales data out of an old database? Get ready for a long ride. You’ll have to map your legacy database to the new service’s schema, you’ll have to figure out how to port the data automatically–especially if you have a lot of records, and you’ll still have to manually review the imported data after the fact. When remapping fields from an old database to a new one, you would usually try to make changes to the old database first to make it look more like the new database rather than trying migrate and remap at the same time. You may also consider allotting some extra time to do data cleanup before the migration. It’s sort of like moving to a new house–when you’re packing up the old one, you should take the time to cull out the stuff you don’t need before you seal it all in a box and ship it to your new house.

Now that you’re planning to put all of your precious business data into a basket outside your business walls, you’ll need an answer to the question: will your data in the cloud be more or less secure than it was in your infrastructure? If it’s more secure, then selling the plan to the worriers within your company will be fairly straightforward. On the other hand, sometimes (though not often) it’s less secure. Yet all is still not lost. Sometimes the benefits of cloud services are so pronounced that having a known security exposure is worth it especially if the impact of a security breach can be quantified and doesn’t result in permanently pissed off customers. Direct this pitch at your CFO — he or she can best quantify the upsides and the risks in order to make a measured judgment. Your network security team would gladly lock everyone’s laptop in a vault and have employees pass handwritten memos instead, which might be more secure, but would also have a dramatic impact on productivity.

Finally, coming up with a plan do the move. More specifically, you should come up with a worst-case scenario plan: what are you going to do if the migration doesn’t work as expected? If you and your team can answer that question, everything else will seem easy in comparison. This worst-case scenario plan should not only include standalone replacement services that you can fire up temporarily, but also a plan for the customers you will need to communicate the situation to and how you’re going to explain it to them. Obviously you will often not know exactly what might cause a migration problem, but it’s good to at least have the skeleton of an email ready to shoot out in the middle of night (because you’re definitely not doing a migration like this in the middle of the day, are you?).

Here at Plum, we ran our own email servers almost 10 years ago. The headaches started piling up: we’d run out of disk space, the email server was extremely slow for large inboxes, there was a torrent of spam that we couldn’t block fast enough. Moving all of our email accounts to a cloud provider took a month to plan and a few weeks to execute. We thankfully didn’t run into any show-stopping disasters but in hindsight, that is probably because our migration plan took three weeks to execute. We went very, very slowly, but we haven’t had to think about our email servers since. Those two months of effort has bought us years of peace.