Changing software partners feels risky, but staying with a failing one is usually riskier. Putti, an Auckland team that takes over projects from other vendors for New Zealand businesses, has rarely started from scratch. With a clean handover you keep the work that's already been paid for.
Do you have to rebuild when you switch?
Almost never. The existing code, data and infrastructure can usually carry forward. The job is a controlled transfer of ownership and knowledge, not a fresh start, and that protects both your budget and your timeline.
A rebuild throws away the parts that worked and repeats the discovery that produced them. It's the expensive answer to a question the audit hasn't asked yet.
What should you secure before you talk to the vendor?
Make sure you actually control what you've paid for. That means the source code in a repository you own, with full history. It means the hosting, domain, app store and cloud accounts in your name. It means the intellectual property assigned to you in writing, so ownership is unambiguous, and the documentation and credentials handed over, not held hostage.
Do this before the conversation about leaving, not after. A vendor who senses a dispute can lock you out in an afternoon. Check that your contract assigns the code to you in writing, and get legal advice if it's unclear.
How does a clean handover work?
The incoming team reviews the codebase first, so it understands what's there before it promises a plan. Then it transitions with enough overlap that knowledge transfers rather than disappears. A short audit sits in the middle of that, and it's the point where you find out whether the answer is carrying on or rebuilding.
If your build was offshored or vibe-coded, our vibe code handover and project rescue services are built for exactly this. Most takeovers run 4 to 12 weeks from getting access, and how a rescue works shows what happens in each stage.
What if the old vendor has gone quiet?
You can still move. Work out what you can recover through the accounts you already hold, then get the code reviewed. Our guide on what to do when your developer disappears covers the first few days in detail.
Tell us who you're leaving and why and we'll tell you what a handover would involve.
Last updated: November 2, 2026
Frequently asked questions
-
Can I switch software vendors in the middle of a project?
Yes, and it's often the right call when the current one is failing. The risk is in how you do it, not whether. Secure your code and accounts first, let an incoming team review the codebase before they promise a plan, then overlap the transition. Done that way, the work you've paid for carries forward.
-
Who owns the code I paid a vendor to write?
It depends on your contract, which should assign the intellectual property to you in writing. Check it before you do anything else. If it's silent or unclear, get legal advice early. Whatever the contract says, the practical goal is the same: a repository you own, with full history, and accounts in your name.
-
What if my vendor holds the hosting and domain accounts?
It's common, and it's the first thing to fix. Ask for the logins or a transfer into accounts you own. Do it before any dispute starts, ideally framed as routine housekeeping. If the vendor refuses, your contract and registrar records are where to look, and an incoming team can often work out what's recoverable.
-
How long does it take to move to a new software vendor?
It depends on the size of the build, but a rescue-style takeover at Putti typically runs 4 to 12 weeks from getting access to a delivered product. The first two weeks go on recovering accounts and reading the code. A longer overlap with the old team makes the transfer smoother, if they're willing.
-
Will I lose my data or my users when I switch?
Not if the handover is planned. Data and infrastructure normally carry forward because the new team works with what exists rather than rebuilding it. Back everything up before the transition starts, keep the live system running while the new team reviews it, and move changes across in staged releases rather than one big switch.
-
Do I need my old vendor to cooperate?
It makes the transfer faster, but you can manage without it. What you need is access: the source code, the accounts, the database and any documentation. A cooperative vendor adds a handover call and answers to questions. If they've gone quiet, an audit of the code itself still tells the new team what's there.