The Vendor Migration Rollout Pattern

Switching observability vendors is risky. The dual-write pattern that lets you migrate safely.

Phase 1: dual-write

Vendor migration rollout is the structured process for moving observability data from one vendor to another with low risk. The pattern uses dual-write, dual-read, and finally drop-old phases. Each phase is reversible until the final cutover; the team can move at the pace that produces confidence.

What phase 1 looks like:

• Old vendor and new vendor both receive telemetry.: The OpenTelemetry collector or similar layer fans out to both vendors. The same data goes to both; the collector handles the duplication.
• New vendor's data is observed but not relied on.: The team explores the new vendor's UI, builds dashboards, configures alerts. The old vendor remains the operational source of truth; the new vendor is the candidate.
• Confidence builds.: Over weeks, the team sees the new vendor handling the data. Queries work; dashboards show the right values; the operational story is becoming clear. The confidence is built through use.
• New vendor's UI gets familiar.: The team spends time in the new vendor's UI. Engineers learn the query language; on-call learns the alerts; product owners learn the reports. Familiarity reduces the operational risk of switching.
• Cost is doubled during the phase.: Sending data to two vendors costs twice as much. The phase has bounded duration; the doubled cost is part of the migration budget.

Phase 1 is the cheapest phase to back out of. If the new vendor turns out to be wrong, the team simply stops sending to it; nothing else is affected.

Phase 2: dual-read

Phase 2 shifts the operational reliance to the new vendor. Dashboards point at the new vendor; alerts fire from the new vendor's data; the team's primary view is the new vendor.

• Dashboards read from new vendor.: Production dashboards switch to query the new vendor. The team's day-to-day operations use the new vendor; the old vendor remains in dual-write but is no longer the operational source.
• Old vendor is fallback.: If issues with the new vendor surface, the team can revert specific dashboards or queries to the old vendor. The fallback is available; rollback is fast.
• Alerts still go to both.: Alerts fire from both vendors during this phase. The duplication catches discrepancies: alerts that fire from one vendor but not the other indicate vendor-specific issues to investigate.
• Most usage shifts.: The team's interaction is mostly with the new vendor. The operational habits shift; the new vendor becomes the default.
• Issues with new vendor surface and get fixed.: Real operational use surfaces real operational issues. The team finds and fixes the issues; the new vendor's reliability and quality improve over the phase.

Phase 2 is when the migration becomes irreversible. The team has invested in the new vendor; rolling back requires walking back significant operational change.

Phase 3: drop old

The final phase is dropping the old vendor. Ingestion stops; the old vendor's data ages out per the contract; the migration is complete.

• Old vendor: shut off ingestion.: The collector configuration is updated to send only to the new vendor. The old vendor stops receiving new data; the data already there ages out.
• Data retention runs out per the old contract.: The old vendor's contract specifies retention. As data ages past retention, it is deleted by the vendor. The team's data eventually exists only in the new vendor.
• New vendor: only target.: The migration is complete. The team operates exclusively on the new vendor. The old vendor is decommissioned per the contract terms.
• Migration complete.: The team's day-to-day work no longer references the old vendor. Documentation is updated; runbooks are migrated; new team members never see the old vendor.
• Plan the contract end.: The contract with the old vendor ends per its terms. The team plans the contract end carefully; data export, final retention, financial close-out all need attention. The migration is complete only when the contract is fully closed.

Vendor migration rollout is one of those operationally complex transitions that benefits from disciplined phasing. Nova AI Ops integrates with multiple observability vendors during migration, supports the dual-write and dual-read patterns, and produces the per-phase visibility that the team needs to migrate with confidence.