Customer migrations for API providers

Ship the upgrade.
Bring your customers.

Give your customers a reviewed path to your next SDK version, with changes they can inspect, verification in their own environment, and pull requests they control.

Explore a migration

Read-only product demonstration. No account needed.

Demonstration One release. Separate customer paths.Not live activity

Provider / reviewed release

deepgram-sdk

Python migration

6.1.17.0.0

Versionlane-curated

One reusable package.
Distributed by invitation.

A Customer environment ACustomer-owned runner

01InvitationAccepted
02Proposed changes3 bindings
03Customer verificationChecks passed
04Maintainer reviewDraft PR

Draft PR awaiting review · Illustrative outcome

B Customer environment BCustomer-owned laptop

01InvitationAccepted
02Proposed changesRuntime blocker
03Customer verificationNot run
04Maintainer reviewNo PR

Unsupported runtime · no PR · Illustrative outcome

C Customer environment CCustomer-owned environment

01InvitationReceived
02Proposed changesNot requested
03Customer verificationNot run
04Maintainer reviewPending

Next step pending · Illustrative outcome

Optional return path: consented status only. No source code, diffs or test logs return to the provider.

01 / Beyond the release notes

Your release is ready.
Your customers still have work to do.

A new SDK and a migration guide tell teams where to go. Their developers still have to find affected code, make the changes, test the result and get it reviewed.

Versionlane gives API providers migration software they can distribute: a reusable reviewed upgrade, verification in each customer’s environment and a draft PR their maintainers control.

Help customers make progress and give your SDK or developer-experience team a clearer next step. Less repeated support work and better adoption are the intended benefits—not guaranteed outcomes.

Review once. Distribute a path.

Your operator reviews a supported migration and sends invitations through your release or support channels.

Meet customers in their codebase.

Their developers preview the edits, verify locally or in GitHub Actions, and inspect the proposed change.

Follow permissioned progress.

See bounded outcomes customers share. Recognise blockers without receiving their source code or test logs.

02 / Explore the product

A migration you can inspect.

See the supported Deepgram Python upgrade, its recorded verification and the maintainer’s review. This read-only demonstration never runs code or sends data.

Proposed changes, before you run them.

One of the three reviewed bindings is shown below. The import moves; the existing alias and application settings are preserved. The SDK pin changes exactly.

− Beforedeepgram-sdk==6.1.1

from deepgram.agent.v1.types.agent_v1settings_agent_speak_one_item import (
    AgentV1SettingsAgentSpeakOneItem as VoiceSettings,
)

voice = VoiceSettings(provider={
    "type": "deepgram",
    "model": "aura-2-asteria-en",
})

+ Proposeddeepgram-sdk==7.0.0

from deepgram.types.speak_settings_v1 import SpeakSettingsV1 as VoiceSettings

voice = VoiceSettings(provider={
    "type": "deepgram",
    "model": "aura-2-asteria-en",
})

All three supported mappings and pack identity

AgentV1SettingsAgentSpeakOneItem → SpeakSettingsV1
AgentV1SettingsAgentSpeakOneItemProvider_Deepgram → SpeakSettingsV1Provider_Deepgram
AgentV1SettingsAgentThinkOneItem → ThinkSettingsV1

SHA-256 ce8e0bfbeae4bae3715bc216d0760eef4dd06ebe69282ef0478b5b39fc1615fb

Other types and ambiguous usage need manual review. Supported repository conditions →

Verification in the customer’s environment.

Recorded controlled acceptance, 8 October 2026. These results belong to the builder’s designated test repository, not to an external customer.

Versionlane verification

Real SDK fixtures · 6.1.1: 7 passed
Real SDK fixtures · 7.0.0: 7 passed
Repository baseline test: 1 passed
Repository candidate test: 1 passed
Execution: Restricted, secret-free Docker

Recorded in the owner-controlled engineering acceptance repository on October 8, 2026. The repository is private; these results demonstrate the machinery, not customer adoption.

A draft for the maintainer. A decision for the team.

A condensed presentation of controlled acceptance PR #3. Publication prepares a review; it does not accept the change.

Draft PR

Migrate Deepgram Python SDK 6.1.1 → 7.0.0

2 files changedExact SDK pin + reviewed binding editsControlled acceptance

What Versionlane checked

The original generated patch, independent SDK fixtures and separate baseline/candidate repository tests. Evidence is tied to the verified base and patch.

What you review

Inspect each changed line and the verification artifacts.
Run ordinary repository checks for the current PR commit.
Mark ready and accept through your normal process, or close to decline.

Customer edits are protected. Later edits make earlier evidence stale. Versionlane never merges automatically.

Controlled draft PR #3 was reviewed in the private engineering acceptance repository. No customer adoption or deployment claim.

Blocked example A Python 3.9 deployment cannot use this target SDK.

The target requires Python 3.10+. An explicitly declared Python 3.9 deployment produces NOT_ELIGIBLE with a runtime blocker.

No automatic patch or PR follows. The customer can address the runtime requirement, then run a fresh preview. Unsupported work stays visible rather than becoming a successful migration.

Illustrative repository condition · reviewed runner rule, not a new customer attempt.

03 / The provider’s view

Know the next step.
Respect the boundary.

Consented reports can show outcomes, blocker categories and a PR’s last reported state. Unreported work remains unknown.

Release progressIllustrative records · No live telemetry

Customer environment	Shared outcome	Next step
Environment AOpted into status and PR link	Draft PR · reported open	Maintainer review and current repository CI
Environment BOpted into status only	Runtime blocker	Review target Python requirement
Environment CStatus sharing off	Not reported	Unknown · customer decides whether to share

Customer-reported metadata, not independently attested execution. PR state reflects its last received update; it is not proof of deployment.

04 / Customer control

The upgrade is yours.
Their code stays theirs.

Run where the customer works.

Verification runs on their laptop or customer-owned runner, inside restricted, secret-free containers. The control service never executes customer code.

Keep the evidence with the developer.

Source, diffs, filenames and test logs are not sent to the control service. Customer-owned local or GitHub artifacts support their review.

Sharing starts off.

Status reporting is optional. Repository and PR links need separate consent. Enrollment alone does not mean a migration was attempted.

Maintainers make the call.

Review a draft, run ordinary checks and accept or decline. Human edits are protected. No automatic merge or production-equivalence claim.

Read the customer requirements and review process

05 / Current availability

An early product.
A concrete starting point.

Versionlane’s working scope is one curated Python migration. The provider workspace is for provisioned operators; registration is not open.

Supported demonstration pack

deepgram-sdk · Python

6.1.17.0.0

Three reviewed generated-type binding changes and an exact dependency update.

Repository scope and limitations

One project with one root requirements.txt and exact public PyPI pins; pytest must be pinned.
Deployment Python 3.10+; runner Python 3.11.
Committed, clean GitHub checkout; explicit application source paths and nonempty offline pytest tests.
Lockfiles, monorepos, private indexes, editable/VCS dependencies and custom builds are unsupported.
Other generated types, dynamic or ambiguous bindings, re-exports and unresolved annotations need manual review.
Tests and deployment settings are preserved. No production API calls or deployed-application equivalence are verified.

Versionlane-curated. Deepgram is not a customer or partner. Recorded controlled acceptance is engineering evidence, not customer adoption.

Give your next version
a path into their code.

Explore a migration Contact Versionlane