Vendor dependency review
Decide where a managed service is worth its switching cost and where an exit path matters.
The decision
Which dependency would be expensive to reverse?
Assumptions and limits
Lock-in is not automatically bad. Evaluate its benefit against the cost and likelihood of switching.
Describe your situation
Decision context
Is this vendor on a critical customer path?
- Yes
- No
- Unclear
Decision context
Have you tested a realistic data and workload exit?
- Yes
- No
- No documented plan
Dependency exposure
Are non-portable dependencies and their owners recorded?
Include APIs, identity, deployment formats and operational tooling. A standard protocol does not prove behavioral portability.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Data and continuity
Does exported data preserve usable meaning and relationships?
Check versions, identifiers, attachments, permissions and audit context, not only whether an export file opens.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Data and continuity
Has an alternative met the hardest required workflow?
Compare the same acceptance cases, limits and failure behavior. Similar feature names are insufficient.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Commercial and operational exit
Are termination, export and residual payment terms understood?
Use the actual agreement and renewal dates. Technical migration does not cancel a contractual commitment.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Commercial and operational exit
Can customers continue while identity and integrations move?
Review credentials, callbacks, DNS, customer identifiers and downstream dependencies during overlap.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Value and review trigger
Is the value gained from this dependency explicit?
Compare measured operating benefit with switching exposure and an agreed review trigger. Portability has its own cost.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
How this tool works
Each selected answer maps to a stated observation and a check to perform. Answers are not weighted, added together, or converted into a score, diagnosis, or automatic recommendation.
An unknown answer identifies evidence to collect. Review each observation against your system and constraints; one favorable answer does not establish overall readiness or fit.
Model assumptions
- Lock-in is not automatically bad. Evaluate its benefit against the cost and likelihood of switching.
- Responses are self-reported and have not been independently verified.
Is this vendor on a critical customer path?
Yes: Availability and commercial terms are part of the architecture.
Check: Test failure modes, data export, and support commitments.
No: A managed dependency may be a good trade.
Check: Document the owner and review trigger.
Unclear: The dependency map is incomplete.
Check: Trace the user journey and deployment chain.
Have you tested a realistic data and workload exit?
Yes: The exit path is evidence-backed.
Check: Record migration time, data format, and residual costs.
No: Switching cost is unknown, not necessarily unacceptable.
Check: Run a narrow export and restore rehearsal.
No documented plan: An exit assumption should not be treated as a plan.
Check: List non-portable APIs, data formats, and contract constraints.
Are non-portable dependencies and their owners recorded?
Yes, supported by evidence: Switching exposure is tied to named dependencies rather than a vendor label.
Check: Update the inventory when a proprietary capability is adopted.
Partly, with known gaps: Visible dependencies are mapped, but hidden operational coupling may remain.
Check: Trace one production journey and record provider-specific behavior and its accountable owner.
No, the check is not met: An exit estimate can miss the parts that cannot simply be redeployed.
Check: Trace one production journey and record provider-specific behavior and its accountable owner.
Unknown, not verified: Missing evidence prevents a conclusion. Include APIs, identity, deployment formats and operational tooling. A standard protocol does not prove behavioral portability.
Check: Trace one production journey and record provider-specific behavior and its accountable owner.
Does exported data preserve usable meaning and relationships?
Yes, supported by evidence: The export can be assessed as a usable recovery input.
Check: Keep a dated representative import and reconciliation result.
Partly, with known gaps: Some records are readable, but omitted relationships or permissions limit reuse. Resolve the prerequisite's remaining gaps before making the stated commitment.
Check: Import a permitted sample into an alternative and compare completeness, relationships and access behavior.
No, the check is not met: A successful export does not yet provide a workable exit dataset.
Check: Import a permitted sample into an alternative and compare completeness, relationships and access behavior.
Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check versions, identifiers, attachments, permissions and audit context, not only whether an export file opens.
Check: Import a permitted sample into an alternative and compare completeness, relationships and access behavior.
Has an alternative met the hardest required workflow?
Yes, supported by evidence: At least one alternative has bounded capability evidence.
Check: Record gaps, adapter changes and the conditions that invalidate the comparison.
Partly, with known gaps: The common path works, but an essential exception may still block switching.
Check: Test one critical exception and one failure case against the same application contract.
No, the check is not met: The exit plan relies on an unverified functional substitute.
Check: Test one critical exception and one failure case against the same application contract.
Unknown, not verified: Missing evidence prevents a conclusion. Compare the same acceptance cases, limits and failure behavior. Similar feature names are insufficient.
Check: Test one critical exception and one failure case against the same application contract.
Are termination, export and residual payment terms understood?
Yes, supported by evidence: The exit decision includes known contractual constraints.
Check: Have the contract owner confirm applicable terms before committing to an exit date.
Partly, with known gaps: Some terms are clear, but notice, retained access or remaining payments need review.
Check: Ask procurement or the contract owner to record notice dates, export access and residual obligations.
No, the check is not met: A technical exit schedule could miss the commercial decision window.
Check: Ask procurement or the contract owner to record notice dates, export access and residual obligations.
Unknown, not verified: Missing evidence prevents a conclusion. Use the actual agreement and renewal dates. Technical migration does not cancel a contractual commitment.
Check: Ask procurement or the contract owner to record notice dates, export access and residual obligations.
Can customers continue while identity and integrations move?
Yes, supported by evidence: Exit continuity is broader than copying the main dataset.
Check: Rehearse the smallest customer journey across the proposed transition.
Partly, with known gaps: Core data can move, but customer access or integrations may interrupt service. Resolve the prerequisite's remaining gaps before making the stated commitment.
Check: Map access and integration changes, failure handling and the responsible support team.
No, the check is not met: The proposed switch lacks an end-to-end continuity plan.
Check: Map access and integration changes, failure handling and the responsible support team.
Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Review credentials, callbacks, DNS, customer identifiers and downstream dependencies during overlap.
Check: Map access and integration changes, failure handling and the responsible support team.
Is the value gained from this dependency explicit?
Yes, supported by evidence: The team can explain why the dependency is worth retaining under current conditions.
Check: Revisit the decision at the recorded cost, reliability or contract trigger.
Partly, with known gaps: Benefits are plausible, but their magnitude or expiry conditions are not established.
Check: Compare a representative operating period and define what change would make an exit worthwhile.
No, the check is not met: Neither retaining nor removing the dependency has a defensible value case yet.
Check: Compare a representative operating period and define what change would make an exit worthwhile.
Unknown, not verified: Missing evidence prevents a conclusion. Compare measured operating benefit with switching exposure and an agreed review trigger. Portability has its own cost.
Check: Compare a representative operating period and define what change would make an exit worthwhile.
Hypothetical worked example
These illustrative inputs are not your result, a customer case, or a benchmark. Change the inputs above to review your own situation.
- Is this vendor on a critical customer path?
- Unclear
- Have you tested a realistic data and workload exit?
- No documented plan
- Are non-portable dependencies and their owners recorded?
- Unknown, not verified
- Does exported data preserve usable meaning and relationships?
- Unknown, not verified
- Has an alternative met the hardest required workflow?
- Unknown, not verified
- Are termination, export and residual payment terms understood?
- Unknown, not verified
- Can customers continue while identity and integrations move?
- Unknown, not verified
- Is the value gained from this dependency explicit?
- Unknown, not verified
Resolve the flagged prerequisites before committing to this decision
8 applicable prompts reviewed. 2 flagged prerequisites need owner review before the affected use or commitment. These are self-reported observations, not proof of readiness, a maturity grade or a recommendation to buy a service. Even an all-positive review needs supporting evidence.
- Is this vendor on a critical customer path? The dependency map is incomplete.
- Have you tested a realistic data and workload exit? An exit assumption should not be treated as a plan.
- Are non-portable dependencies and their owners recorded? Missing evidence prevents a conclusion. Include APIs, identity, deployment formats and operational tooling. A standard protocol does not prove behavioral portability.
- Does exported data preserve usable meaning and relationships? This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check versions, identifiers, attachments, permissions and audit context, not only whether an export file opens.
- Has an alternative met the hardest required workflow? Missing evidence prevents a conclusion. Compare the same acceptance cases, limits and failure behavior. Similar feature names are insufficient.
- Are termination, export and residual payment terms understood? Missing evidence prevents a conclusion. Use the actual agreement and renewal dates. Technical migration does not cancel a contractual commitment.
- Can customers continue while identity and integrations move? This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Review credentials, callbacks, DNS, customer identifiers and downstream dependencies during overlap.
- Is the value gained from this dependency explicit? Missing evidence prevents a conclusion. Compare measured operating benefit with switching exposure and an agreed review trigger. Portability has its own cost.
Checks for this example
- Trace the user journey and deployment chain.
- List non-portable APIs, data formats, and contract constraints.
- Trace one production journey and record provider-specific behavior and its accountable owner.
- Import a permitted sample into an alternative and compare completeness, relationships and access behavior.
- Test one critical exception and one failure case against the same application contract.
- Ask procurement or the contract owner to record notice dates, export access and residual obligations.
- Map access and integration changes, failure handling and the responsible support team.
- Compare a representative operating period and define what change would make an exit worthwhile.