The Need to Manage Office 365 Feature Deprecations
Managing Office 365 Change
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.
Deprecations Happens On an Ongoing Basis
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
- Exchange legacy in-place holds and eDiscovery tools, including the Search-Mailbox The old SharePoint eDiscovery Center has also mostly disappeared. Microsoft says that Office 365 eDiscovery cases and content searches offer better capabilities.
- SMTP authenticated connections. This is an important topic for devices like printers and copiers that use Office 365 to send email notifications.
- Classic Azure Information Protection client. AIP first appeared in 2016, but its role inside Office has been taken over by Office 365 sensitivity labels.
- Office 365 Video The first iteration of a video processing and management service within Office 365, now in the final phase of the migration to Stream.
- Basic authentication for Exchange. Replaced by modern authentication because it is a gaping hole for hackers to probe with techniques like password spray attacks.
- Skype for Business Online is being replaced by Teams.
- StaffHub, introduced in 2017 and based on Office 365 Groups, now replaced by the Shifts app in Teams.
- Delve blogs and classic SharePoint blogs. Never developed by Microsoft with any passion or drive, it’s surprised that these blogs have lasted as long as they have.
- The phasing out of support for less secure versions of connection protocols like TLS 1.0 and 1.1.
- Clutter (retirement postponed in December 2019). The Focused Inbox came from Outlook mobile (Acompli) and is better than Clutter, but some insist that they prefer Clutter and forced Microsoft to postpone its removal.
- Yammer has changed enormously since Microsoft acquired it in 2012. The latest set of changes in the “year of Yammer” launched at the Microsoft Ignite 2019 conference refocus Yammer on communities and knowledge sharing in a single network per tenant. Organizations using multiple networks will need to fold them into a single network.
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.
Microsoft Drives the Process
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.
The Cycle Continues
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…