Transfer everything from old computer to new computer with Windows 11
Transfer programs and files to new computer
Transfer files from one computer to another
Transfer Microsoft Office to new computer
Restore programs and files from a broken or dead computer
Transfer directly from an old hard drive
Transfer to new computer using a USB hard drive
Corporate Windows 11 migration
User Profile Migration to new PC / new domain
How To Migrate Local Profiles to Azure AD
Migration to Server 2019 / 2016
Transfer everything from old computer to new computer with Windows 11
Transfer programs and files to new computer
Transfer files from one computer to another
Transfer Microsoft Office to new computer
Restore programs and files from a broken or dead computer
Transfer directly from an old hard drive
Transfer to new computer using a USB hard drive
Corporate Windows 11 migration
User Profile Migration to new PC / new domain
How To Migrate Local Profiles to Azure AD
Migration to Server 2019 / 2016
Transfer programs and files to new computer
Transfer files from one computer to another
Transfer Microsoft Office to new computer
Restore programs and files from a broken or dead computer
Transfer directly from an old hard drive
Transfer to new computer using a USB hard drive
Move To New PC - Compare Options
Migration Kit Pro - Advanced Transfer
Transfer programs and files to new computer
Transfer files from one computer to another
Transfer Microsoft Office to new computer
Restore programs and files from a broken or dead computer
Transfer directly from an old hard drive
Transfer to new computer using a USB hard drive
Server 2012 migration seems to be a major theme in end-client requests these days, now that support for Server 2012 is officially ended. Similar to 2003 and 2008 EOLs, the official “End of Support” date tends to mark not the end of migration project, but rather the start. Most MSPs and IT teams will see 2012 migrations as an ongoing theme for quite a while. In this article, we’ll cover some common “lessons from the trenches”, best practices, migration automation options, and lessons learned.
Just want to read about automating the migration?
Click here to skip to the migration automation part.
An interesting aspect of Server 2012 EOS is that it is not a *total* end of support – there is a loophole. If you move a 2012 server to an Azure VM, you get 3 more years of special “Azure Extended Support”. It’s a great move on Microsoft’s behalf to encourage the move to Azure infrastructure, and does allow a protected way to keep using 2012 for a little longer – at least as a stop-gap solution, or for workloads that are incompatible with a newer OS (more on that below).
We are migrating from 2012, but to what? 2022 seems like the obvious answer, but that is not always the case. There is a 10 year gap between 2012 and 2022. More importantly, 2022 has (intentionally) dropped several compatibility paths that 2019 included, in order to allow the OS architecture to move forward more freely. This means that you may find some applications that are incompatible with 2022 – but are compatible with 2019.
Of course, that does not necessarily mean that you should stay with 2019 for your entire datacenter. From what we see so far, it’s a question of percentages. If you find that almost all of your servers are incompatible with 2022, then adopting 2019 as the current primary target OS makes sense (and then starting to look into upgrading those core business applications to 2022-compatible level pretty much immediately). Otherwise, whenever possible, opting for 2022 as target does remain the preferable option, with 2019s used for specific workloads where required – or even keeping some 2012s with Azure Extended Support, as a compatibility stop-gap.
How to actually perform the migration efficiently (and without pulling your hair out) certainly remains a major question in any server migration project.
The main issue with migrating to a different OS is that typical “lift-and-shift” / clone options are not applicable: you still end up with server 2012.
For file servers, you do have the option to manually copy data (e.g. rsync / robocopy), and recreate the shares, which is relatively doable if there aren’t too many of them. There also exist specialized migration tools for specific common workloads such as SQL or IIS (webdeploy).
Of course, there’s also Zinstall WinServ, which migrates applications, profiles, shares and data, automatically. We see it used by MSPs and IT teams in organizations of all sizes, for projects ranging from just a few servers to several hundreds (and even thousands, although generally we wouldn’t recommend migrating a thousand servers at the same time…).
You can get a eval copy of Zinstall WinServ here, and try it on your own servers.
The great thing about native migration automation like that is that it is completely generic in terms of which applications you transfer, and what platform / OS you transfer to – 2022 or 2019, on-prem or Cloud. You can migrate from an on-prem physical 2012 to an on-prem 2022 VM, from an on-premise Server 2012 to an Azure Server 2022, or from a Private Cloud 2012 R2 server to an EC2 Server 2019. You can even use this to implement an in-place upgrade of a Server 2012 running on Azure / AWS.
Can you automate *everything* in a typical server migration? Probably not. You still need a pro “behind the wheel”, and there is always initial setup and post-migration adjustments and verification to perform. But if you can automate 80-90% of the busywork – it changes everything.
You can also contact us for assistance, evaluation licenses or any info that may help.
