Before discussing a replacement platform, I want a precise answer to a smaller question: what is difficult about operating the environment today?
The answer might be unsupported software, unreliable recovery, inconsistent access, slow changes, or too many exceptions for a small team to understand. Each points toward a different solution. A smaller inventory is useful only if it improves the responsibilities behind it.
Source
What current guidance adds to the decision
Microsoft’s Strangler Fig guidance, updated in June 2026, describes replacing application functionality in stages. It also makes the transition cost visible: old and new systems coexist, shared dependencies need attention, and the routing layer can become a bottleneck or a point of failure. The pattern is less suitable when a small system can be replaced simply or the original must be retired quickly.
That is an application migration pattern, not a universal infrastructure prescription. What I take from it is a useful discipline: evaluate the temporary arrangement as carefully as the destination.
OpenTelemetry’s May 2026 blueprint initiative addresses another part of the problem: how useful components fit into an understandable operating setup. Together, these examples leave me asking how much of the current burden comes from the platform and how much comes from the way it is assembled and supported.
Synthesis
Separate the problems before choosing the project
I would put the current issues into three groups.
An ownership problem means people cannot reliably identify who maintains a service, approves a change, or responds to a failure. A new platform will still need those answers.
A consistency problem means similar services behave differently because configuration, access, monitoring, or documentation has drifted. Standardizing a small set of practices may be the most useful first change.
A capability problem means the current arrangement cannot meet an important requirement at an acceptable cost or risk. That may justify replacement even when ownership and configuration are clear.
These groups can overlap. The point is to avoid asking one migration to solve three problems without saying how it will do so.
Proposal
Give the options a common test
Imagine a firm whose reporting process depends on several servers, a scheduled export, and a spreadsheet that only one person understands. Consolidating the servers might reduce maintenance while leaving the fragile handoff intact. Moving the spreadsheet into a new application might create a better record of changes while introducing a new integration to support.
I would compare three proposals: improve the existing arrangement, replace the weakest component, or migrate the whole workflow. For each, name the intended improvement, the new dependencies, the transition work, and the continuing owner.
The acceptance conditions should describe behavior. Can a second operator diagnose a failed export? Can the firm reconstruct which data informed a report? Can it restore a usable service within an agreed window? Those questions make the alternatives easier to compare than a feature list does.
Treat coexistence as a system of its own
A phased migration creates a period when responsibility is divided. That period needs a clear rule for where new data belongs and which system is authoritative.
I would define a representative pilot, a reconciliation method, and a cutover decision. The pilot should include an awkward but ordinary exception, such as a changed record arriving after an initial transfer. A clean demonstration using only easy records will reveal less about daily operation.
Rollback also needs precision. If people have already created new information in the replacement system, returning traffic to the old one may leave two conflicting histories. The plan must account for those writes before calling rollback an available option.
The CRM migration acceptance record provides a starting point for records, permissions, relationships, and workflow checks. Other environments will need different evidence.
Proposal
Define retirement before the pilot expands
Every temporary integration needs an owner and an ending condition. Keep a list of dependencies that must be removed, records that must be retained, and access that must be revoked before the old environment can close.
My starting preference is the smallest change that produces a meaningful operating improvement. I would move faster when an unsupported dependency creates a material exposure that cannot be contained. I would slow down when a proposed consolidation concentrates failure or creates support demands the team cannot meet.
The useful outcome is an environment that another person can explain, maintain, and recover. That is the standard I would use to decide whether the modernization earned its cost.