The CIO’s Modernization Test: What Can The Business Safely Retire?

Getting a new platform live is an important milestone. It doesn't necessarily mean the business is ready to let the old one go. Sometimes that's the right decision—teams may need historical records, certain services must remain available, and a period of overlap may protect operations. What concerns IT leaders is when nobody can explain why the old environment is still needed, or what would allow it to be retired.

In information access, hosting transitions and platform-consolidation assessments, three questions have become particularly useful: Can people still do their work? Who supports them after the change? What are we still paying for? These belong in the original business case, not on a list of loose ends after go live.

Business Capability

A recent mailbox-capacity alert brought the first question into focus. After updating archive settings, the IT team needed to explain where older messages would remain accessible and that the change hadn't deleted them. The configuration was only part of the work—the person using the mailbox also needed to know where to find their correspondence.

That same requirement matters in larger transitions. A finance team may need an old record to investigate an invoice. An operations manager may need to confirm an earlier customer commitment. Before retiring a system, organizations need to understand those needs well enough to preserve them.

Start with the business owner: What information is needed, who needs access and what task does it support? Work with records and legal stakeholders to establish retention requirements. Then decide which arrangement meets them. The acceptance test should reflect actual work—ask an authorized employee to retrieve a record, interpret it and complete the relevant task.

Operating Ownership

During a Microsoft 365 consolidation assessment, device-management components, identity applications and conditional access policies required further scoping beyond standard migration objects. These details affect how the environment will be supported afterward.

Who will administer access? Who handles a device that no longer meets policy? Who resolves an exception involving both the new environment and a retained service? These responsibilities should be settled before the handover. Naming a provider in a project document isn't enough—the agreement needs to explain what that provider owns, what remains with the internal team and how problems crossing boundaries will be resolved.

Financial Closure

In hosting-transition reviews, organizations must examine which services can be discontinued and what limited support may still be necessary for legacy systems used primarily for historical reference. Scope, contractual commitments, responsibilities and pricing all need to be understood.

A migration milestone doesn't tell finance when previous charges will stop. A smaller supplier invoice doesn't necessarily mean the work disappeared—some responsibilities may have moved to internal employees or another provider. The comparison needs to cover the full arrangement: new recurring costs, retained services, transition expenditure, overlap and the capacity required to support it.

Be precise about the benefit. Removing a recurring charge, postponing expenditure and transferring work are different decisions. Forecast savings should remain forecasts until changes are implemented and results can be checked. Where overlap is needed, explain what it protects and what will allow it to end.

Separating Go Live

Treating technical go live and business completion as distinct approval points helps ensure thorough evaluation. Go live confirms the replacement is ready to operate against agreed technical criteria. The completion review confirms that required workflows have been accepted, support responsibilities are understood and continuing commitments have been reconciled.

A one-page decision record can organize this review around the three questions: business capability, operating ownership and financial closure. Include supporting evidence, unresolved exceptions, accountable owners and next decision dates. The answer may be that a legacy service needs to remain—this can be sound when its purpose and obligations are clear.

What organizations should avoid is retiring something necessary to make a project look finished, or keeping it indefinitely because no one owns the decision. Modernization gives leaders an opportunity to reconsider what the business needs, not simply replace what it already has.