When your platform is shutting down, treat the vendor's end date as a deadline minus a buffer, not the date itself. Spend the first two weeks inventorying what depends on it and confirming the dates, pick a path per service by week four, and finish cut-over at about 70% of the window. We'd do it in-house unless services outnumber owners with spare time; then bring in a bounded DevOps engineer.
How long do you really have after a platform announces a shutdown?
Less than the headline suggests, and often not a single date. A vendor's notice usually carries several clocks: when the service switches off, when you can still export data, and when support or maintenance ends. Your plan runs on the earliest of them that you can't recover from.
Vendors differ on whether they give dates or durations. Atlassian gave dates for Opsgenie: end of sale on 4 June 2025 and end of support on 5 April 2027. Deno gave a duration. Its 9 October 2026 post says Deno Deploy "will continue operating for six months before shutting down" and gives no calendar date.
Say your API and two webhook workers run on Deno Deploy, you're an 8-person B2B SaaS, Postgres sits on a managed provider, and CI runs in GitHub Actions. Counting six months from the post gives about 9 April 2027, our reading of when the clock started, so the first job is to confirm it. For the news itself, see Deno's six-month Deploy shutdown.
Which date counts: service-off, export window or support end
Plan against service-off, and check the export window separately, because some vendors close downloads before they close the service. Support-end dates matter less for hosting than for tools you can keep running unsupported. Deno's runtime is a different clock again: it gets another year of monthly releases with bug fixes and security updates, and stays open source. In our example, that's a problem for a CI job in about October 2027, not for the April cut-over.
What to do on day one
Save the notice with its date. Then email the vendor and ask in writing for the exact dates and how long they keep your data after closure. A written answer settles the question when a blog post only gave a duration.
How to run a platform shutdown migration in six steps
The schedule below counts days from the announcement, using the Deno example. If you're reading this weeks after your notice, start from today's day number and compress the inventory, never the buffer.
1. Save the notice and set the deadline (days 0-2)
Take the vendor's service-off date, subtract a buffer, and write the result at the top of the plan. We'd put the cut-over target at roughly 70% of the window, and use the remainder for stragglers, rollbacks and surprises. For the example, that means all services live on new infrastructure by day 126, about eight weeks before the April date.
Tell the board or your co-founders the target, not the vendor's date. If an agency chose the platform for you, ask them the same day for the repo list, the account owners and the deployment config.
2. Inventory what depends on the platform (days 1-14)
List every service on the platform, its owner, the proprietary features it uses, the data stores, the CI and config that touch it, and the scheduled jobs. A repo search finds imports but misses Dockerfiles, CI workflow files, environment variables and cron definitions, so open the deploy config and the CI settings by hand.
In the example, the inventory finishes on day 14. It finds three services on Deploy and one CI job that runs the Deno runtime.
3. Pick the path per service (days 15-28)
Choose one path for each service: move to the vendor's suggested target, replatform to a standard host, rebuild the part that depends on proprietary features, or retire the service. IS&T's cloud-migration checklist lists six options (rehost, replatform, refactor, repurchase, retain, retire), and for a shutdown "retain" drops out, because staying isn't available.
The example settles on day 28. The API moves to Node.js containers on a standard host. The two webhook workers go to Cloudflare Workers, the destination Deno names and supports for paying customers.
4. Staff it (by day 28)
If there are more services than owners with spare time, bring in a DevOps engineer now; otherwise run it in-house. In the example, three services and two available owners mean in-house. If neither owner had room, this is the week a DevOps engineer starts.
5. Migrate one low-risk service first (days 29-56)
Pick the service with the fewest dependents and move it end to end, then time it. No source publishes migration hours per service, so this pilot is how you get yours. Hyperping, a monitoring vendor, puts a careful Opsgenie migration at four to eight weeks including a parallel run. Your own pilot number resizes the rest of the plan.
The example's first webhook worker is live on day 56, and the team records how long it took. If the pilot ran well over your estimate, move the staffing decision back on the table now, not in February.
6. Cut over in waves, freeze, decommission (cut-over days 57-126, decommission by day 154)
Move the remaining services one at a time, lowest risk first, and keep the old platform running until the new one passes its checks. Export your data before the export date you confirmed on day one, and freeze changes on a service while it moves.
In the example, all three services are cut over by day 126, with Deploy still running as a fallback. By day 154, Deploy traffic is zero, the config is exported and the account is closed. That leaves four weeks before the end, about day 182.
Which path: move with the vendor, replatform or rebuild?
Move with the vendor's suggested path
This is the cheapest route when your code already fits. Deno points Deploy users to Cloudflare Workers and offers migration support to paying customers. Atlassian points Opsgenie users to Jira Service Management or Compass. The catch is that you're choosing a vendor's preferred destination, so check what it costs and which of your features it lacks before you accept the default.
Replatform to a standard host
Containers on a mainstream host are the safe middle path, and they're why we'd move an API off a runtime-specific platform. You change deploy config and some code, but you keep the option to move again. The cost is that you now own more of the operations that the platform used to hide.
Rebuild the proprietary part
If a service depends on a feature nobody else offers, you either rebuild that part or retire it. This is the path that burns schedule, so start it first. When a no-code platform's limits force a rebuild shows the same decision on a different kind of platform.
Do it yourself or hire a DevOps engineer for the move?
Count the services on your inventory, then count the owners who know them and have spare time this quarter. One or two services with owners who can spare it: run it in-house, because the knowledge sits with the people who'll be on call afterwards. More services than owners with spare time, or a target that needs skills nobody has: bring in a bounded DevOps engineer by day 28, because a late migration costs more than a short engagement.
Keep your product engineers in charge of the deploy path either way. In the Hacker News discussion of the Heroku announcement, one commenter said their company hired a full devops team to save about $5,000 a month on Heroku and ended up with a much worse developer experience. That's one anecdote, but it matches how handovers fail: the people who ship daily stop understanding how their code reaches production.
For the cost side of staffing the move, see the labour behind a cloud migration.
What this means for your deadline and budget
You're making two decisions in the first four weeks: the cut-over date and who does the work. Write the cut-over date as the vendor's service-off date minus your buffer, and hold your team to that one. Don't let the vendor's date become the plan.
Then settle staffing by day 28. If your owners have capacity, the migration costs you their time and nothing else. If they don't, the question is whether a few weeks of senior DevOps help costs less than the delay and the product work you'd drop. We'd say it does, once the inventory shows more services than owners.
If the move also exposes that nobody owns infrastructure, the startup CTO guides on leadership and first hires cover who should.
Hiring a DevOps engineer for a bounded migration
If the inventory shows more services than owners with spare time, the move is a short, scoped job, not a permanent hire. HighCircl matches senior DevOps engineers within 72 hours, which keeps most of your window for the migration itself. There's no minimum hour commitment, so you can scope the engagement to the pilot and the cut-over waves. Hire a DevOps engineer through HighCircl.
FAQ
How long do I have when a platform announces a shutdown?
Until the service-off date minus a buffer. Confirm the date in writing, because export and support dates can differ from it. Plan to finish cut-over at roughly 70% of the window.
What do I do if the vendor gives only a duration, not a date?
Count from the announcement date and treat the result as your working deadline, then ask the vendor to confirm. Deno's 9 October 2026 notice gave six months and no date, so a team should plan against about 9 April 2027.
Is it a shutdown if a vendor moves a product to maintenance only?
No. Heroku's February 2026 move to sustaining engineering says the platform stays supported and production-ready. That's a signal to review your options, not a deadline.
Do I need a DevOps engineer to migrate off a platform?
Not if the move is one or two services with owners who have spare time. If the inventory shows more services than owners with capacity, a bounded DevOps engagement by week four costs less than a late migration.
Which of the R's in cloud migration applies when the vendor shuts down?
Rehost, replatform, refactor, repurchase and retire all apply, and "retain" doesn't. You choose one per service in step 3.