The email that starts the clock
The notice rarely comes from anyone you can argue with. A hosting environment is being retired, a group IT function is consolidating platforms, or a supplier is winding down a service. The message has a date in it and no author who can move that date. Somewhere on that environment runs an integration that nobody has thought about for years, because it has never needed thinking about. Leads land where they should. The records on both sides stay in step. It simply happens.
Now you have a deadline you did not set, for a system you did not build, and the person who built it is no longer on the payroll. The integration is not broken. It is about to lose its home, and you are the one who noticed.
Working is not the same as owned
An integration that has run without complaint for years looks like an asset. It is closer to an unmanaged one. It was built as a project deliverable, signed off, and never converted into a service that somebody operates. The hosting was chosen once, by whoever was convenient, and never revisited. The documentation, where it exists, describes how the thing was built rather than how it behaves in production: what it does when a record fails validation, what it does when the other side is down, who gets told.
Ownership is the real gap. The integration sits between two systems, and each owner assumes the other is responsible for the middle. That is invisible while everything flows. On the day it stops, two people explain that the fault is on the other side, and sales asks where this week's leads went.
So the move is only half the job. The other half is an owner who can be reached.
Inventory before you migrate
Do not move anything until you can answer four questions about the integration, in writing.
- Which records. Not the object names from the original specification, but what actually crosses today: which entities, which fields, and which are transformed on the way. Pull a sample from the last month and compare it with the specification. They usually differ.
- Which direction. One way, two way, or one way with exceptions. Two way syncs have conflict rules, and those rules often live in someone's head.
- How often. Scheduled, event driven, or a mix. A nightly batch and a real time trigger fail differently and are watched differently.
- What happens on failure. Retry, queue, drop, or alert. Who receives the alert today, and does that person still work for you.
The answers become the acceptance criteria for the move. Without them, "it works on the new hosting" means "nobody has complained yet", which is how you got here.
Moving under a fixed date
The first question we are asked is whether it can be done before the date. The answer is yes if three things are true. The inventory above exists or can be built in the first week. Somebody on your side can grant access to both systems and the old environment without a month of ticket routing. And the old environment stays reachable long enough for the two to run side by side, because it is your fallback until acceptance.
We take migration and stabilisation as one piece of work with one acceptance point, not a project and then a support conversation. Acceptance is not "deployed". It is: the records in the inventory cross in the expected direction, on the expected schedule, and a deliberately provoked failure produces the alert to the named person. That check needs the old environment still running, so acceptance falls before the decommission date. Plan backwards from acceptance, not forwards from the notice.
After cutover
Cutover day tells you very little. Scheduled jobs need several cycles before you can trust them, and month end processes only show up at month end. Treat the period after the move as a named phase, stabilisation, with someone watching the logs and the alerts rather than waiting for a user to notice. The integration behind this post was live in production, and acceptance came at the end of the stabilisation window, not on cutover day.
The objection at this point is usually budget: there is no line for an ongoing support arrangement. There was no line for this emergency either, and the emergency is the more expensive and worse timed of the two. The arithmetic is in support hours that expire.
Making the next one boring
Two things turn the next decommission notice into a task rather than a crisis.
The first is a handover document that describes the running behaviour, not the build: which records cross, in which direction, on what schedule, who holds the credentials, what each failure mode looks like from the outside, whom to call, and the date somebody last verified it all. That last field changes behaviour: a verification date that has not moved in years is itself the alert. The template below is the one we hand over.
The second is a reachable owner. If that is your own team, the document and the failure modes are what they need. If it is not, ours is a prepaid pool with a named responder that does not expire. A fix, an infrastructure change or a further integration all draw on the same pool, so no time is lost arguing whether a task counts as support or as a change. For procurement: one arrangement instead of a monthly retainer, and nothing that stops your own team taking over later.
