On April 11th this year, Exchange Server 2007 will reach the end of its support lifecycle, otherwise known as end-of-life. For customers still running Exchange Server 2007, you should start making plans now to migrate to a newer version of Exchange, or to Office 365. In fact, I’d love it if you would take a moment to answer my poll question to share what your plans are.
Exchange Server 2007 Service Pack 3 (the last service pack that was released in June of 2010) reached the end of mainstream support in April 2012. When mainstream support ends, products go into an extended support phase for another few years. Products in extended support usually receive no further feature updates, but continue to receive security updates and some bug fixes. The extended support period for Exchange 2007 ends on April 11th, 2017. After extended support expires, the product received no further updates at all.
The release of Exchange Server 2007 (on March 8th, 2007 according to TechNet), marked a significant milestone for the Exchange Server product, as well as for my own career. Exchange 2007 was a big shift from previous versions of Exchange, moving to a 64-bit architecture, separate server roles, PowerShell administration, and giving us the first use of log shipping for database replication that is now such an important part of the Exchange Server and Exchange Online high availability architecture.
When Exchange 2007 arrived on the scene I was working as a generalist server administrator, and had just moved from a managed service provider to a project/consulting role. My manager at the time gave me a few options for specialization. I could focus on SCCM (which I’d been dealing with since SMS 2.0), SharePoint (which was just starting to show some momentum in the enterprise, and looked challenging), or Exchange. I had worked with Exchange since 5.5 through my various support roles, and we happened to have more Exchange projects in the pipeline than anything else (plus I was a little burned out on SCCM, since I was generally called in to fix completely broken implementations), so I agreed to focus on Exchange. In hindsight, I feel like I made the right choice.
Over the next few years I migrated lots of customers to Exchange Server 2007, with a variety of deployments including some CCR clusters and at least one SCR (Standy Continuous Replication) deployment, which I actually had to activate for that customer after they duffed their primary server one day. Along the way I started blogging about Exchange Server on a personal blog, which eventually turned into Exchange Server Pro, and has now evolved into Practical 365 (which you’re reading right now).
I embraced PowerShell early when I realized how much easier it would make my server deployments, and dove in even more deeply after landing a job at one of Australia’s largest Exchange orgs where it would be impossible to manage and troubleshoot the environment without PowerShell. It was in that role that the earliest versions of some of my most widely used PowerShell scripts were developed – Get-MailboxReport.ps1 and Test-ExchangeServerHealth.ps1. Both of them are showing their age today, having being written for an Exchange architecture that has evolved quite a bit over time, but for the most part are still working.
Despite my fondness for Exchange Server 2007 and all the good it has done for me over the years, it is definitely time for customers to move on. Your servers won’t suddenly break when the end-of-life date passes, but running software that has no vendor support is extremely risky. If a serious bug or security vulnerability emerges, or if your server crashes and you need help restoring data or services, Microsoft won’t be able to help you. Finding third party support will also get more difficult as Exchange 2007 skills fade or move on from the job market into other roles.
If on-premises servers are how you still want to run your Exchange, then a migration to a newer version should be planned as soon as possible. Ideally you will migrate to Exchange Server 2016 as the latest and greatest, but that will require a two-stage migration from Exchange 2007 to 2013 first, then Exchange 2013 to 2016.
Your other option is to migrate to Office 365. Email is a good first workload to migrate for organizations who are new to cloud services. There is a migration path from Exchange 2007 to Exchange Online. A hybrid migration is a good option to consider, and Microsoft offers a free “hybrid license” of Exchange 2013 that you can install in an Exchange 2007 organization to facilitate the hybrid connectivity and migration (you just can’t host mailboxes on the free hybrid license). If a customer hasn’t had the time to maintain or upgrade their Exchange 2007 servers for this long, moving to the cloud and making it Microsoft’s job to maintain the infrastructure is an excellent idea. You also get access to all of the other features of Office 365 that don’t exist on-premises, such as Planner, Teams, Office 365 Groups, and many more security and compliance tools.
So don’t delay. Start making those plans. And don’t forget to take a minute to answer my poll, or share your thoughts in the comments below.
