With Office 365 now approaching ten years in production, it’s not news that Microsoft has removed some features. Indeed, because the first two iterations of the servers used in Office 365 were akin to their on-premises counterparts, it was inevitable that they would discard old code created to meet the needs of single-server on-premises deployments with code designed to exploit the cloud. Today’s focus in Office 365 is on new applications like Teams and Planner and base functionality that operates across all workloads, like Office 365 retention policies and data loss prevention.
Change within Office 365 needs to be managed. Most of the time, we consider how to deal with the introduction of new functionality and pour over the plans in the Microsoft 365 roadmap and details released closer to availability as notifications in the Office 365 admin center. Microsoft and independent blogs are consulted to gain insight into what’s happening and understand the impact on a tenant. Perhaps scripts are built to assemble and note information about new features. Tracking new Office 365 developments and putting them in context for an organization can become a full-time job.
Microsoft uses deprecation as the term to describe the removal of a feature or app. In other words, they want to remove the technology because it is no longer useful or has been replaced by something better, more advanced, or more functional. Perhaps the feature was the first attempt to create a solution in a specific area, or it is limited in terms of what it can do.
Recent examples of change where functionality is removed or replaced
The list goes on with the point being that deprecation happens continuously inside Office 365.
Now that we’ve established that Microsoft removes or phases out features and functionality from Office 365 on an ongoing basis, the question arises of how to track and manage this change. The introduction of new functionality causes changes to user training, updates for support, new documentation, and so on. Shouldn’t the same happen for deprecations?
My feeling is that few organizations do a good job of managing the dark side of change. Microsoft posts notifications in the Office 365 Admin Center to tell people when deprecations happen and to set a deadline for action. After that, it’s up to the tenant to make whatever changes are needed to cope with the withdrawal of a feature or protocol. This should be a straightforward process but often it’s not and Microsoft ends up postponing a deprecation to accommodate customers.
A valid argument can certainly be advanced that the timelines for deprecation selected by Microsoft suit their plans rather than customers. This is inevitable. Microsoft has done the work to figure out why a deprecation is necessary and how they will deliver replacement functionality. They announce a decision to customers and run into the simple fact that Office 365 tenants come in all shapes and sizes. Some consider a deprecation to be a disaster; others don’t care; and some tenants don’t do anything because other priorities seize their attention.
Microsoft could force deprecations through. Normally they don’t, at least not as the first response after meeting customer pushback. The usual approach is to extend the deadline by six months or so to give tenants more time to handle the problem. Hopefully that’s enough, and eventually the time arrives when a feature like Delve Blogs stops working and disappears from clients. If everything is done right, tenants won’t be surprised. At least, that’s the goal.
Nothing stays static in the cloud. Applications flex and evolve. I suspect we could all handle the down side of change better to make sure that Office 365 tenants are prepared for deprecations. I can but dream…