Moving a service to a cloud provider can be a very beneficial activity (reducing cost, piece of mind, transfer of risk), but it can also create a huge amount of problems if not done correctly.
We will not delve into what SLA and service conditions are agreed on with your service provider. We will focus on the migration process.
Assuming you have selected a service to migrate to a cloud provider, and have selected the cloud provider, even after contract signing, things may still be far from complete. The migration process is the thing that can be very painful and can break the entire service for an extended amount of time.
And sadly, the service provider may not be too interested in properly supporting you in the migration process, for whatever reason.
To ensure a successful migration, or at least to be able to 'pull on the handbrake' before disaster strikes, make sure that you check the following elements before driving into the migration process:
- Clearly understand what data from the current service will be migrated into the cloud service - this is crucial from several points of view: If there is migration, you must understand the amount of data can and will be migrated, whether the service provider has sufficient space to accept all data or you'll need to prioritize and whether the format of the data remains the same. For instance, you may be using a MySQL database but are migrating all data into an Oracle cloud service. Also, if data is not migrated, you'll need to keep it available to the users as legacy data.
- Clearly understand the migration process of the data from local into cloud service - if existent the migration of data can vary wildly. It can depend on very complex factors like change of format, structure, proxying etc, or very simple like bandwidth to transfer the files over.
- Understand authentication source of the cloud provider - all your services were authenticated to a data-set within your company, usually a LDAP server or a database. You must understand which data-set can the cloud provider support for authentication, because you may need to recreate your user's accounts and generate and distribute new passwords to them.
- Gather all usage scenarios of the service as it is currently delivered (in house) - there may be multiple usage scenarios for a service that have been introduced through the years, either officially or unofficially. For instance, a mail server can be accessed via POP3, IMAP, MAPI (on Exchange servers), and different users may be using different protocols.
- Confirm which usage scenarios are supported by the service provider - your users may need to be reconfigured in advance or at the moment of migration. You need to understand which steps you'll need to take to maintain minimum outage for the users. This is usually tightly connected to the authentication source and set-up.
- Ensure you have bandwidth - Going into the cloud means remote access. And whatever your in-house service was, you never cared about bandwidth usage and latency over your gigabit LAN, but that bandwidth usage may be very significant. Observe your current network using network analysis tools and learn more about broadband packages that you use, especially their flexibility to quickly increase bandwidth or decrease latency if needed on roll-out time.
- Know who to call - at time of migration and right after that, things are going to be hectic, issues will rise all over the place, and your team will be less than their usual competent self, since they'll also be using a service. Have all of them read through the SLA and the communication and escalation procedures of the cloud contract. This way the issues will be escalated rapidly, and support call will be made much faster.
- Understand your fallback options - any migration can go wrong. In order to be able to continue your original service in such a scenario. Investigate whether your original service will be available during after the migration, and look and test for any risks that the migraiton may leave your in-house service broken. This may be a huge issue if somehow there are problems.
- Make a plan with outage period and ability to go back to your service - before you go into migration, make a plan for the migration, in which you'll define the migration period start and finish times based on testing results. The entire period of migration should be planned as downtime, and the source service should be in a 'frozen state' (no new entries in it). The reason for such a downtime is two-fold: Even if the migration is online, if anything goes wrong, you are under less pressure to fix it, and by creating a frozen state of the source service creates a point-in-time to which you are prepared to revert in case of trouble.
- Inform everyone of the pending change - spread the word, the customers should be well aware of the change. Informing everyone is about people being able to plan and adapt if the service is out, but it also helps you and your team - you'll get more feedback and discover overlooked items, and during the crunch time the users will give you more breathing time instead of jumping on your throat because their service is not working.
Migrations are a very stressful time for everyone, and hopefully the above points will help both you and your customers survive them in a smoother manner.
Talkback and comments are most welcome...
Cross-posted from ShortInfosec