Last month Microsoft started sounding the "end of support" death toll for Exchange 2007. Admins have a year to plan and migrate to either Office 365 or a newer version of on-premises Exchange. (If you go with on-premises Exchange, I recommend Exchange 2016 because Exchange 2013 is already three years into its 10-year support cycle and Exchange 2016 is a slightly beefier version of Exchange 2013 -- basically, you get three extra years of support by adopting Exchange 2016.)
Some people accuse Microsoft of holding to a strict end-of-support strategy -- which often gets labeled "end of life," though the software still functions to continue extracting money from customers' IT budget. While there might be some truth to that argument, it ignores the fact that much has changed in technology in the decade since Exchange 2007 was released.
Exchange Server 2007 introduced a five-server-role deployment scenario, PowerShell, and continuous replication availability options. Since then, we've seen Exchange 2010, 2013, and now 2016 improve performance dramatically, alter server roles down to a single internal role (Mailbox) and single external role (Edge, which few deploy), enhance PowerShell (now at Version 5), and impressively enhance continuous replication in the form of database availability groups (DAG). If you are still on Exchange 2007, it's time to move forward.
The same can be said of other software that Microsoft develops, both desktop and server. Although Microsoft could continue to spend resources on existing products, to maintain patches and security updates and such, there is no solid financial return on that investment when compared to creating new versions that require a full upgrade. Microsoft has to make money to stay afloat, like any other business.
Microsoft of course is doing more than pushing upgrades -- it is campaigning for a subscription- and cloud-based future through Azure and Office 365, with a rapid cycle that takes the release cadence to the limits.
Some in IT complain that the rapid cadence is a mistake because it causes sloppiness, as we've seen with Windows 10. I don't disagree per se, but I do prefer a speed at which mistakes can be rectified. That's not a speed we've seen in the past.
In fact, in the past, IT organizations would wait until Service Pack 1 before deploying Microsoft software because the first production release was always filled with holes. You would wait three years for a new version, ignore that first clunky version of whatever software, then wait another year for the first Service Pack before you were comfortable.
Whining that Microsoft is "making money" on the upgrade cycle would get more sympathy from me if we weren't talking about a 10-year gap. It's not like Microsoft hold its hands out every three years and forces the move forward -- or else. When you consider the changes in hardware, the changes in a network environment, security woes, and so forth, 10 years is a long time between forced migration cycles.
Sign up for CIO Asia eNewsletters.