Your API shipped a breaking change. Your customers' code didn't notice.

Portover scans the codebases that consume your API, proves which call sites break, and opens the migration PR: diff, test results, and a citation for every change. A human reviews. Nothing merges itself.

Run a pilot with your API See how it works

Right now: migrating open-source repos off the OpenAI Assistants API before the Aug 26 shutdown. 3,829 repos mapped on the dying surface so far.

▸3 GitHub permissionsmetadata, contents, pull requests. Nothing else.
▸Fresh sandbox per repoan isolated microVM, destroyed after the PR opens
▸Credentials stay outsidetokens live at the proxy, never in the sandbox
▸Never auto-mergeenforced in code. Uninstall revokes everything.

How it works

Three steps between your changelog and your customers' green CI

01 · detect

Your change, made machine-readable

We diff your OpenAPI spec, SDK releases, and changelog into a signed migration manifest: what broke, what replaces it, how to verify the fix.

02 · prove

Impact, with receipts

For each consenting repo, static analysis narrows the candidates and an agent confirms every affected call site, with the line of code as evidence. No match, no noise.

03 · open the PR

The fix arrives where work happens

Diff, test run against a pre-change baseline in an isolated sandbox, citation per hunk. Your customer reviews and merges. We never can.

Why this exists

Deprecation notices don't migrate code

9,000,000

weekly npm downloads still hit AWS SDK v2, ten months after end-of-support.

api.npmjs.org, July 2026
16–22%

of developers who react to a deprecation at all fix every deprecated call. The rest patch around it or delete the call.

Sawant et al., ICSME 2016
20.1%

of supposedly-safe minor and patch upgrades contain breaking changes anyway.

Ochoa et al., EMSE 2022

Every API team knows the pattern: you announce early, write the migration guide, extend the deadline. A year later a fifth of your traffic is still on the old surface. The missing piece was never communication. It's that someone has to open their editor. We open it for them.

For maintainers

Did you get an issue or PR from portover-bot?

Then your repository uses an API surface with an announced shutdown date, and we built the migration for you. A few things you should know:

  • We asked first. We open an issue and only send the PR if a maintainer says yes. If we got that wrong for your repo, tell us. That's a bug on our side.
  • Every change is cited. Each hunk links to the provider's migration guide, and the PR body includes test results from a sandboxed run against your existing suite.
  • Nothing merges without you. The bot cannot merge, approve, or push to protected branches. Close the PR and we won't reopen it.
  • Opting out is one comment: write @portover-bot opt-out anywhere, or email hello@portover.dev, and your repo goes on the never-contact list the same day.

Who's behind this

Built by someone who runs this in production

I'm Nader, a senior AI and cloud engineer, previously co-founder and CTO of AI-RE. In both roles I ended up building the same thing: automation that does the maintenance work nobody has time for. The latest version runs in production on a legal-tech product: user feedback goes in, a root-caused ticket with reproduction files comes out, then a tested fix-PR. A wrong answer there is a legal problem, so every change carries its evidence. Portover applies the same discipline to the messiest recurring chore in software: moving everyone off the old version.

Running a deprecation and dreading the support queue? Talk to me about a pilot.