Before you ask the board to approve leaving a vendor the company depends on, stress-test the exit. Map the contract notice window, how long a full data export really takes, the months you will pay for both systems, and every customer who will notice the switch. Then make sure you can extend the old contract if the migration slips, because a notice sent too early can leave you with no service at all. Paste the contract, export documentation, migration plan, and customer-facing dependencies into one request. Instruct Pingpong to flag notice deadlines that arrive before the migration is proven, data that will not come out in usable form, dual-running costs missing from the budget, and customer obligations the plan ignores. Review your written answers in a second round.
This page is for executives preparing to exit a major vendor with board approval. Counsel owns contract and legal review. Pingpong checks the plan for consistency and readiness. For choosing the replacement, see war-game a vendor selection before the board approves the contract. Executive starting points live under Pingpong for executives.
Four clocks run at once
- Contract: the notice deadline, the renewal date, and whether you can extend month to month if needed.
- Data: how long a complete export takes, in what format, and what the vendor will not export at all.
- Dual run: the months you pay both vendors while traffic moves.
- Customers: who has to do something, who has to be told, and what your own contracts promise them about changes.
Exit plans usually track the first clock and guess at the other three.
Why exits stall
Leaving a vendor feels decisive in the meeting. The trouble starts later, in details nobody owned. The export runs, and a field the team relied on comes back empty. A customer's security team asks for three weeks to review the new setup. The engineers assigned to the migration get pulled back for a launch. The vendor knows the notice date too, and has little reason to be flexible. Experienced teams build slack into every clock and secure the right to stay longer before announcing they are leaving.
A worked example
This example is illustrative and does not describe a customer. A 450-person software company uses an outside provider for customer sign-in. At renewal, the vendor proposes a 60 percent price increase, worth about $1.4 million a year, after three outages in twelve months. The contract renews in seven months, and notice is due 120 days before renewal, so it must go out within three months.
The technology leader pastes the contract, export documentation, migration plan, single sign-on customer list, and customer contract clauses about service changes.
A useful pass finds that the export does not include password data in a form the new system can use, so all 2.1 million end users would be forced to reset their passwords at cutover. The plan budgets $0.8 million and four months, but leaves out three months of paying both vendors, about $0.45 million, and five engineers taken from the roadmap for six months. Some 140 enterprise customers would need to reconfigure single sign-on, and 12 of them have contracts promising 30 days' notice of authentication changes. If the migration slips past renewal after notice has gone out, the company has no right to keep the old service running. The plan has no point to stop and reconsider.
The revised plan starts with counsel negotiating a six-month month-to-month extension at a capped rate, signed before notice is sent. New sign-ups move first. Existing users migrate when they next log in, which leaves forced resets only for inactive accounts, about 15 percent. Single sign-on customers get a 60-day window and named support, and the 12 with notice clauses get formal notice early. The full cost comes to $2.1 million, which the avoided increase pays back in about 18 months.
What the board approves
- The reason for leaving, with the cost of staying stated as plainly as the cost of going.
- The full exit cost, including dual running and the roadmap work that waits.
- The extension right, signed before notice.
- Customer impact by group, with the obligations you owe each one.
- Go and stop points, and who decides at each.
A request you can copy
Below are our vendor contract, the export documentation, our migration plan, customer-facing dependencies, and relevant customer contract clauses. Build a timeline of notice, export, dual run, and cutover. Flag data that will not export in usable form. Add missing costs. List customer obligations the plan does not meet. Check whether we can extend the old contract if we slip. Suggest go and stop points. Stop there so we can answer in writing, then review our answers.
How Pingpong runs the review
The web review app sends your request through several models in order. Each later model receives the original request and every earlier answer, with instructions to assess the work so far. For the steps inside the app, see running your first review.
What a model can't review
A model cannot predict how the vendor will behave once it knows you are leaving, or how patient your customers will be. It can make sure the plan allows for both.
When the decision goes to the board, see war-game a decision before the board meeting. More guides live under work decisions before you commit.