Success Story: 5 Lessons on Migration to Azure Cloud

Also read on KO.COM.UA (in RU)

Suppose, a company brought all its internal processes to perfection, and local systems and hardware are working like a charm. Will this miracle last forever? Of course, sooner or later you‘ll need to upgrade. Does it all mean that migration to the cloud will be as easy as ABC? Sadly, it is not like that.

Read five quick lessons on migration to the cloud, presented by Infopulse, the official Microsoft CSP in Europe, and based on our recent infrastructure migration project conducted for a large B2B IT services provider headquartered in the EU.

Cloud Transformation for a Major IT Services Provider

The customer of Infopulse is a large European company, which grew by buying smaller companies. As is often the case in such situations, our customer inherited many legacy systems and obsolete servers. When the cost of support began to exceed profitability and efficiency in general, the customer thought of switching to cloud technologies. About this time, companies began to get rid of rapidly aging hardware on a large scale and to standardize technological stacks.

It was back in 2014 when our multi-stage project started. Since then, it has been lasting for several years and consisted of two main and several intermediate stages:

• Migration to Office 365 (SaaS) and building a hybrid Exchange Online cloud. The project was implemented with an active participation of the Infopulse project team in the course of 2 years.
• Migration of the data centers to Azure (IaaS) and retirement of obsolete servers. The project is still in progress.
  
  Here are the five most important lessons we have drawn from this case.

1. Users’ Migration from Old Systems Takes a Lot of Time.

Deploying and configuring Office 365 from scratch can be done relatively quickly and easily. However, it is not easy at all when, as in our case, we had to migrate data of about 6,000 users from two legacy systems to the cloud. Half of the end-users utilized Exchange 2010, while the second half used IBM Lotus, the system that had known better days but was still popular at that time in Europe.

Technically, the migration turned out to be very complex and took almost 2 years – a seemingly unrealistic period of time. The whole process of migration looked like this:

Picture 1. Integration between Azure AD and On-Premises AD

Picture 2. Data Migration to Office 365

The rate of migration was limited since we had to design an individual approach to each end-user. Due to the large volumes of user data, we could only migrate from ten to twenty users per day, using special software. And let’s not forget about all those numerous software conflicts and incompatibilities, that slowed down our progress!

Was it worth the effort? For sure, because the results of migration were perfect for the end-users. We made a universal integration of all accounts into a unified infrastructure without losing a single kilobyte of data, and everyone on customer’s side is now using modern cloud services.

It is worth noting that business activities were in full swing during migration – the data transfer did not affect users’ working capacities. Still, it’s not the process that is the most important, but the final results.

Conclusion: Migration projects are not always fast.

Much depends on the current technological stack, on infrastructure features, on tools compatibility, and on many other factors. To understand time limits and scope correspondingly, evaluation of all these factors is one of the top priorities, and should be conducted before the migration project. In any case, all companies have to go through the difficulties of migration at some point. Thus, the sooner you start, the sooner you will pass to the next stage.

2. Network Infrastructure Should Be Ready Before Migration.

Our customer owns a large number of data centers located in different places in Europe. Some data centers were in a quite neglected state, while for some others their lease was coming to an end. In order not to extend the lease and not to bother with the legacy hardware and its costly support, it was necessary to migrate all systems and servers to the cloud. For these purposes, Microsoft provides Azure Site Recovery, a cloud-based recovery service, which, among other things, allows migrating physical and virtual servers to the cloud.

According to the ASR procedure (and for everything to work properly), it was necessary to put a lot of effort into building and setting up a proper network infrastructure. Infopulse’s dedicated team dealt with this task, which was to provide a fine connection between local and cloud servers, as well as with the software for Azure that allows seeing virtual machines. We had to come up with a full-scale design: draw and plan all steps, create the network, establish a connection, etc. In addition, we also implemented the Microsoft ExpressRoute service, by means of which the local network expands to Azure virtual networks.

Network modernization took about two months. Only after all these procedures were over, we were able to migrate some Active Directory servers, started building services and transferring data to Azure.

Conclusion: Migration is not just a data transfer.

Such projects involve improvement of many other seemingly well-functioning components.

3. Inventory and Documentation – Two Crucial Steps.

Another important step to do before the migration is the server inventory process.  When migrating a large data center, we need to work with hundreds of servers responsible for the operation of a wide variety of services and systems. Which servers should be disconnected, which should be transferred to other data centers, and which should be migrated – it is impossible to clear up all this without inventory and subsequent documentation procedures. In order to understand everything in detail, one should establish communication with the owners of each server and undertake a pilot migration on simple and unnecessary servers. This is exactly what we did, while simultaneously working on the migration plan. This fine-grained document describes all the details of this process, including instructions, which buttons to press, which IP addresses to change, and what to restore – step by step.

After a series of preliminary tests, we managed to finally get our hands on the production servers, and perform their full inventory, specifying all installed services and applications. We also determined their importance and prioritized them, dividing servers into lots according to their criticality. Only after that, we were able to start the migration of the servers.

Conclusion: Well-established communication helps to solve even the most difficult issues.

The percentage of successful tasks completion decreases dramatically if you lack a proper understanding of roles and involvement of all parties in the process.

4. Legacy Systems and Obsolete Servers Require Special Approaches.

The migration of servers required us to develop the whole range of non-standard approaches and techniques.

One of the difficulties we faced was to manage the migration process in such a way, so that our work did not affect the customer’s workflow. In other words, it was impossible to migrate large servers in business hours, because this could affect the availability of services. Therefore, occasionally our team had to work in non-business hours.

However, there were also by far more complex and subtle aspects that had influenced the course of the entire migration project.

For example, many servers were so old that the software used for migration did not support them. To migrate an unsupported server (e.g., a Windows 2003-based) from VMware to Azure, one had to perform an additional conversion:

• First, we used Microsoft MVMC tool to transfer the VMware virtual machine to the Microsoft Hyper-V virtual machine.
• Only after that, Azure supports moving such a machine from on-premises to Azure.

Both listed operations required downtime.

Another example: users of one ancient application had to have a static MAC-address, otherwise, the app would have stopped working. For the moment, one cannot deploy the service with a static MAC address in Azure. In addition, the IP address of the servers changed during migration, making this challenge impossible to deal with. Thus, in this very case we had to leave everything be.

The whole process looked like this:

Picture 3. Migration of Data Centers to Azure

In addition, not all data was transferable, and not all servers could be migrated to Azure – in part because it was extremely difficult. In some cases, we had to recreate the servers and databases manually from scratch.

 Conclusion: Each case is unique.

There are no common multifaceted approaches that could be applied universally even within the framework of one project.

5. Migration is a Resource-Intensive Project. But the Results Recompense Expenses.

Such changes are indicative in the sense that they require a lot of effort and resources from the whole company. The infrastructure of our customer was too outdated per all technical indicators. Moreover, having these huge amounts of old servers in their possession and the pain of extra costs for support, configuration and replacement of expensive legacy repair parts, our client had to put measures in place urgently. On top of it, old systems constantly and regularly crashed. Fixing and paying for the downtimes was much more expensive than migrating everything to the cloud service.

As a result of this project, our customer saved tones of resources and benefited from accelerated processes. Such a universal update of infrastructure should not be deemed as expenses, but solely as an investment in business development, which is rewarded quite quickly. Besides the fact that the cloud service simplifies and automates much of what was previously done by hand, Azure also provides very convenient statistics. Every gigabyte is taken into account, making everything transparent and analyzable. And if you think that a certain cloud server is not needed at the moment, you can temporarily disable it, and keep all the data without paying for the service.

Conclusion: It is not worth sticking with the old technology.

If you follow the “if something works, do not touch it” principle, be wary that it can result in doing more harm than good. The market and its development rate dictate their own terms and call for following the trends and embracing new technologies.

Summarizing the Above

This project’s success was critically important for our customer’s business.

Now that the hybrid Azure infrastructure has been built, most Active Directory servers and services, as well as hundreds of business applications, are based in the cloud. At the same time, many services are managed on-premises, which adds flexibility to control capabilities. Thanks to migration, we managed to consolidate thousands of users, accelerate processes and automate many tasks. All new servers will be initially cloud-based.

Some Statistics, Facts, and Numbers:

• 6,000 user accounts have been migrated;
• About 9,000 active Exchange Online users;
• About 500 active OneDrive users per day;
• About 1,500 pages of SharePoint Online, 200 active pages per day;
• About 1,000 active Yammer users per day;
• 10 physical servers Exchange 2010 have been retired, as well as 4 physical and 20 IBM Lotus 8.5 virtual servers;
• Simplified domain management: 3 Active Directory domains instead of 27;
• Outdated data center closed down: more than 80 servers migrated to Azure; while the remaining 200 servers were either closed or moved to the other data center.

What comes next? The data centers migration project is successfully moving forward. Taking into account the scope of our customer’s business, we’ve got a lot of other projects ahead.

Instead of a Postscript

We can assure you with confidence that even in the most difficult situations it is possible to solve any problem. No matter how big or complex your business may be, do not be afraid of making changes. Remember: technology is primarily a tool, and when in the right hands – it’s a key to your success.