Subscribe to our blog
Thanks for subscribing to the blog.
This second post in our series on data migration details the massive changes that migrating Windows workloads will have on the corporation. Microsoft apps are in constant play in almost every business, and changes will affect most employees. Consider the changes to be a positive — as long as you adopt best practices for workload migration and stay in clear communication with your people.
Migrating Windows workloads is a popular goal for corporations that want to centralize data repositories, stop spending money on hardware, and accelerate go-to-market plans. AWS and its consulting partners offer three migration technology services just for Microsoft workloads:
- Migration. Get premigration assessment and planning and/or automating and managing workload migration.
- Operational optimization. Optimize and automate Microsoft workloads on AWS for security, availability, and manageability.
- Data, analytics, and machine learning. Prepare, transform, analyze, and govern Microsoft SQL Server data for data analytics and machine learning on AWS.
If organizations need migration help, they can get it from AWS and its consulting partners like NetApp.
However, the corporation also needs to be prepared for a migration’s impact on its employees as well as its business. A migration team can have a great plan and near-perfect execution — and the corporation could still lose hundreds to thousands of productivity hours thanks to employee confusion and resentment.
Smart migration teams minimize negative impacts with consistent two-way communication, respectful collaboration, and emphasizing training and benefits.
How migrating Microsoft workloads affects nearly everyone
There are three broad phases of migration that have a broad effect on the corporation: preparation, initiation, and operation.
Premigration: Prepare (discover, plan, design, deploy)
Migrating Windows workloads is never strictly an IT project. Migrating to the cloud does not simply hide a bunch of servers in someone else’s data center. It fundamentally changes business processes, corporate IT budgeting, and user productivity. IT cannot be a migration’s sole enabler but must partner with business units and their executives, and usually with external migration experts.
A migration team should include:
- Executive champion. This executive is accessible, believes in the cloud migration project, and has the relational and organizational clout to champion it. CTO and CIO are popular choices.
- Project manager. This person is an expert in migrating workloads to the cloud and can keep a highly complex project on track. The PM also tracks key performance indicators for cloud performance and cost, and productivity gains (or losses). The PM is often a consultant who is an expert in moving workloads to the public cloud.
- Cloud architect. Cloud architects and senior engineers have an intimate knowledge of the public cloud and how to optimize workloads for performance and cost. This role might be internal or belong to the consultant team.
- System administrator. Administrators work closely with the cloud architects, managing cloud resources in place of computing hardware. They are the boots on the ground for managing software as a service (SaaS), infrastructure as a service (IaaS), and platform as a service (PaaS) — wherever the corporation runs Microsoft workloads. Administrators are usually staff but contracting with managed services like NetApp® Cloud Volumes Service will minimize the number of administrators you need.
- Security. Information security works closely with the corporate compliance team and the cloud provider to identify and protect security in the cloud. Typical security domains include authorization management, key management, encryption, and plugging common vulnerabilities.
- Compliance. Working closely with the security team and the cloud provider, this team creates compliance plans and monitors reports for privacy protection and regulatory compliance.
During the premigration phase, staff and partners who use Windows apps (most of which) will also be involved in fact finding and decision making. The team will need to contact key stakeholders in plenty of time. For example, an unhappy senior vice president can do a lot of damage to such an intricate project. Keep them regularly informed, especially if a prominent business unit is about to lose its favorite software in favor of a cloud-native application.
The team will also need to work closely with suppliers and partners and protect ongoing projects from disruption.
All of this is a big job, and the migration team might find that its internal expertise is either too stretched or nonexistent. This is the time to hire expert consultants like NetApp Professional Services.
Migrate: Initiate (cutover, validate)
Executing the migration takes careful implementation, clear project workflows and milestones, and continual testing and verification.
Slow and steady wins this race. The best plans keep legacy apps running until the cloud application becomes operational. At every step in the process, a failed or suspicious migration can be safely rolled back with no harm done.
It is not at all unusual for large corporations to take 2 years or more to fully migrate a computing and storage environment. This amount of time has nothing to do with enterprise inertia, and everything to do with careful migration methodology and disaster planning. The key is testing: Build and test a proof-of-concept migration. If the move passes the test, then execute and validate.
As with the premigration phase, keep users informed. Alert them in plenty of time, letting them know that their legacy apps are in line for retirement, and share as much knowledge and involvement as possible in the new cloud application. For example, some migrations will be relatively painless, such as moving from Microsoft Office to Office 365. Other migrations, such as phasing out a non-Microsoft collaboration software for Microsoft Teams, will take training and support to minimize productivity losses.
Post-migration: Operate (operationalize, document, close out, monitor)
Verify your monitoring and management applications and update any automation scripts. Document your migration’s plan and execution. This project step is one of the easiest to avoid, but documentation will serve you well as you optimize, and if you need to migrate again. Finally, confirm that all aspects of the migration plan are complete and meet your project requirements.
Never stop monitoring. Adapt to constantly changing platform updates; keep on top of SLAs to make sure you always get the performance you are paying for. And keep a close eye on those costs so you can adjust services to keep your costs to a minimum.
One last thing
Even if the migration goes perfectly, it will still affect the organization in the short term and long term.
Short-term effects include training time, productivity slowdowns, and lots of complaining. Minimizing these issues is a very good reason for the migration team to go slowly, carefully migrating one application at a time.
But long-term benefits include faster go-to-market time, closer collaboration between IT and business units, better communication between different business units, improved DevOps, centralized data access, and better adoption of AI and machine learning.
Migrating Microsoft workloads is a big project and will have a significant effect on the corporation. If you strategically approach migration with careful planning and execution, and clearly communicate with your people, the benefits will far outweigh any temporary inconvenience. Cloud Volumes ONTAP provides robust file sharing services. For more insight into file shares with NetApp on AWS, watch this webcast: The Basics of Migrating to the Cloud with AWS and Cloud Volumes ONTAP.
For more on our migrating to AWS cloud blog series please visit our entries ISV to SaaS: Transitioning from legacy apps to software as a service, Why cloud migration matters from the top (of an organization) to the bottom, High availability in AWS: A fail-safe for cloud deployments, and Are your financial services workloads compliant when migrated to the cloud?