Microsoft’s extended support for Windows Server 2012 and R2 ends October 10th, 2023. EOL means no more security patches, leaving your data and applications vulnerable to attack. Breaches can be costly, both in dollars and reputation. There are some key differences in how you can migrate from 2012 and 2012 R2. Your migrations options are:
Windows Server 2016
Unfortunately, this reaches EOL in 2027, which means repeating the process within a few years.
Windows Server 2019
Support ends in 2029. This option allows you to migrate using an in-place upgrade if you are currently using 2012 R2. You’ll need to manage a two-phase upgrade if currently on Server 2012.
Windows Server 2022
EOL scheduled for 2031. A good option if it meets your application needs.
Hybrid/multi-cloud
Any of the above combined with a multi-cloud strategy for greater flexibility/availability. This will require even more stringent planning to make sure you are optimizing applications and workloads.
How to Migrate
Microsoft has some suggestions:
- In-place upgrade: Keep the same hardware (if it meets requirements) and all server roles. If you’re moving to Windows 2022 from Windows Server 2012, you’ll have to do this in stages (you can only move up two versions) – migrating first to Server 2012 R2 or Server 2016, then to Server 2022. That’s a lot of work!
Note: You can move up three versions from Windows Server 2012 R2 so it is possible to do an in-place upgrade to Windows 2022, as long as all your applications and hardware drivers are compatible. - Clean Install: Install on new server hardware, new server VM, or Cloud VM and migrate applications and data to these new environments.
- Cluster operating system upgrade rollout: Keep multiple servers in a virtualized cluster to ensure redundancy for continuous service. If migrating a cluster, it’s best to install a new cluster and migrate applications and data.
- Migrate: Move one feature or role at a time from a source computer running Windows Server to a destination computer on the new version.
The selected migration strategy will depend on existing hardware and software requirements, which must be investigated by talking to in-house app owners and third-party developers, and by determining hardware compatibility, and/or hardware warranty lifetime. In addition, in-house-developed software may require further development work and testing to ensure proper compatibility with the upgraded OS version
Tackling a server migration?
Learn how to accelerate server migrations while reducing risk and cost.
It’s all about the apps: steps for an MS server migration
Whatever route you take, there are many moving parts. Here are some steps and considerations:
Data Discovery: How many servers do you have? What applications do you support? What hardware do you have? What are the dependencies? You’ll need to map a comprehensive view of all your applications and the databases, servers, teams, and individuals they impact. Start by pulling data from all your tools and databases and aggregate and normalize them.
Identify application and server owners. You’re probably going to need more info than you got from your tools to fill gaps and find owners. That means investigating – you may have to communicate with the teams who use those apps to find out more if you can’t identify an owner.
Survey app owners and teams to understand app requirements and the best migration path. Is any development required to move them into the new server environment? Can they be moved to a virtual server or cloud, or should they remain on-prem? What databases or servers are impacted by the application and how will this affect the next steps? Are they supported beyond 2012 or 2012 R2? Can they be retired or replaced with a similar app that will operate in the new environment? Application rationalization is a good exercise ahead of your move. As is having a plan for exceptions.
Talk to third party app owners to understand their migration path – is there a later version supported in the new server OS that you should migrate to?
Decide your migration path(s).
- Check hardware requirements and begin your refresh if required.
- Use data from third-party and app owners to work out your cloud migration options for apps and workloads.
Test, Test and Test again: it’s all about the apps – in much the same way you would manage your Windows desktop servicing, you’re going to have to test and verify your applications in the new server environment, opening tickets with teams to spin up VMs to test and certify that everything works in the new environment.
Schedule your move: Talk to stakeholders to understand critical business times to avoid peak trading or blackout dates.
Communicate to end users explaining what’s happening and where they can get help if any issues occur.
Cut over to the new environment: Don’t forget to back up your data ahead of the move.
Keep your old server active. If you’ve moved to a new server, keep the old one active for a while in case of any issues.
With many moving parts and dependencies and multiple tasks to manage every aspect of your server migration, the migration path for any application can have multiple sub-projects. The sheer effort of investigating application dependencies and trying to identify owners can take months if done manually. Then you’ll be tied up with compiling workflows using data from multiple spreadsheets. It’s not unheard of for a server migration project to take 18 months!
Use automation to streamline your server migration
By leveraging the digital platform conductor capabilities of ReadyWorks you can reduce the time, stress and effort of migrating to a new server environment. ReadyWorks enables you to:
- Get a real-time view of your servers, application, users and all the complex interdependencies. Ditch the spreadsheets and streamline data discovery by connecting to all your tools to automate the collection, aggregation, and analysis of all relevant information.
- Automate communications and surveys to cut the many months spent mailing back and forth with app owners to understand app requirements. Leverage communication templates and the ReadyWorks self-service portal.
- Create automated workflows sparked by the decisions made about each application, whether migrating to a server on-prem or in the cloud – all managed from a single centralized location.
- Leverage dashboards for clear accountability allowing stakeholders to see progress.
Book a demo to see how ReadyWorks can help you manage your migration from MS Server 2012 and 2012 R2.
