Surely an IT migration must be simpler than moving a people across the world. Surely.
There has been a lot written on the topic of migration. It all started some millions of years ago as the first homo-sapiens moved from their African birthplace across the land to Europe, Asia and beyond. This first migration was not, as far as we know, planned.
More recent migrations, such as the migration to the new land on the Mayflower or from the West Indies aboard the Windrush, have needed more planning.
Quite a lot of what we know can be considered history.
As soon as there were networks, data could be shared. Every upgrade came with its own migration plan. In-place upgrades were not really migrations as no data moved, but, at the same time, the access to the data may have changed.
As networks have changed, there have been migrations from PC-LAN (and its various flavours – Torus Tapestry, OS/2), NetWare 2, 3 and 4, Windows NT or from different email systems (ms-mail, cc:mail, notes, GroupWise and Exchange) – all of which have required data to be migrated to new storage locations at each stage.
Here are some key things to consider when managing the moving parts of a cloud to cloud migration.
Today, we use cloud-based technologies and we don’t have to worry about migrations any more.
Or do we?
We can all remember the planning we did when we migrated to the cloud and hoped that that would be the last migration. Since the cloud is updated at the back-end, there should be no need to migrate again.
So, what happens when your organisation takes over another company? You’re going to want all of the users and data to be in one location. That is going to involve a migration of some kind.
Moving Exchange to Office 365 involved setting up a hybrid. That is still in place and (in the words of the highlander) “there can be only one” hybrid. This means that the email will have to be migrated.
If the new company already has Office 365, then it would be nice if there was a magic switch that just linked the environments. Such a thing does not yet exist (I am sure that Microsoft are working on something, but they have not let on to us yet), so we are faced with a more traditional migration.
The same is true if the organisation is using Google or any other SaaS provider for their identity, authentication, email and data services.
Data in SharePoint online (or on-premises) will have to be moved, as will any OneDrive for Business data. The location where data is going to be held will have to be set up and have the right access controls added.
This doesn’t even look at the other services that may be in use in the tenancy (services such as PaaS or VMs that need to be migrated). If a period of dual running is required how can you guarantee that access is maintained during the migration?
“Moving from cloud to cloud could require data to move down to a data centre first and then up to the new provider, so each piece of data is doubled.”
Of course, companies also spin-up new organisations to take advantage of new markets and these also involve migration. You could describe this as an emigration of users and data, and a merger or acquisition as an immigration.
The availability of the tools become an essential part of the planning and implementation of the migration:
Not least it is important to consider how long a migration could take. The time taken to transfer a file is dependent on many variables, including:
Moving from cloud to cloud could require data to move down to a data centre first and then up to the new provider, so each piece of data is doubled (once in each direction).
Over a 100-megabit line a 10GB file (or files) will take just over 18 minutes (75% utilisation), which seems quite fast – but consider that a VM disk is likely to be over 128GB and there will be many of these to move.
It is very unlikely that all of the services can be moved in a Big Bang approach, so some form of dual running becomes vital until the migration is complete.
The usernames must also be considered. An identifier such as “email@example.com” can only exist in one authoritative directory. More specifically the domain “thirdspace.net” can only be registered in one directory.
Moving this along with the users means that a separate domain name must be used during the transition.
If access to the legacy environment is still required during (or after) the migration, then this transition domain may have to remain in place and active for an extended period of time.
It is clear that, despite having moved to the cloud, the days of having to plan and implement migrations are far from over. New services are coming online, and companies are merging, acquiring or divesting all the time.
Each migration must be explicitly planned for and, in each case, at each stage, a rollback plan must exist and have been tested.
Every migration is different; consideration of any regulatory compliance and other frameworks may modify what is done as part of the migration.
Ultimately, planning is essential. As has been said by many people, “failure to plan is planning to fail.”
If you’re currently looking to undergo a migration and are unsure of the best approach, why not get in touch and we’ll be able to assist with identifying what needs to be done, and how you can implement your migration securely and with control.
Simply request a free Vision Call. We can help you with solution ideas, technology education, best practice advice and more.Request Vision Call
Eight-time winner of the Microsoft Partner of the Year Award for Identity Management, Enterprise Mobility, and Security and Compliance.
You are seeing this because you are using a browser that is not supported. The ThirdSpace website is built using modern technology and standards. We recommend upgrading your browser with one of the following to properly view our website:Windows
Please note that this is not an exhaustive list of browsers. We also do not intend to recommend a particular manufacturer's browser over another's; only to suggest upgrading to a browser version that is compliant with current standards to give you the best and most secure browsing experience.