Assurance · Dependency & lock-in

Ownership map

How many of your critical components you can reach and run — versus how many only your vendor can.

You control

of 71 critical components

Vendor-controlled

reachable only by the vendor

After the transition

100%

target once remediation completes

What this means

Only 8 of 71 critical components are ones Northwind can reach and run on its own; 63 are reachable only by the vendor. Every vendor-controlled component is a point where work stops if the vendor does — the count is the size of the lock-in, not an opinion about it.

Component ownership

Yours Vendor-controlled

Where the lock-in sits

Northwind source repository
The repo lives at bitbucket.org/vantagedigital — vendor-owned. Northwind can't control access or history until it's transferred to a Northwind org.
Vendor~5d to replace
Private Composer registry (composer.vantagedigital.com)
Hosts the 63 vantage/* packages; without a client-owned mirror, composer install fails and the backend can't be built.
Vendor~10d to replace
63 private vantage/* PHP packages
The backend framework — auth (16 pkgs), Doctrine ORM, GraphQL, console, data-patch. Replacing them is a 6–12 month rewrite; the deepest lock-in.
Vendor~270d to replace
@vantage/ui & @vantage/state (npm)
Vendor-maintained but MIT-licensed and public (277 files, 555 imports). Only ~25 components are actually used — forkable in 2–4 weeks.
Public dep~21d to replace
CI/CD Docker image (vantage/sdlc/runner)
Builds run on a vendor-owned image in the vendor's AWS ECR — Northwind can't reproduce the pipeline without it.
Vendor~30d to replace
Production AWS account & infrastructure
Production runs in a vendor-controlled AWS account with no IaC for RDS, Elasticsearch, StarRocks or Kafka.
Vendor~90d to replace
External integrations (Stripe, ES, StarRocks, Kafka, Twilio, iContact)
Third-party services Northwind can hold directly — not vendor lock-in, but the accounts and keys must be moved under Northwind control.
Public dep