How to switch technology providers without losing control of your software

You ask your provider for a small change to your invoices. The reply takes a week, the quote is higher than expected and the explanation doesn’t quite make sense. Last month’s change is still nearly done. And you get the feeling your business depends on someone who doesn’t really know it.

It isn’t an unusual situation, and it’s rarely one side’s fault. But if you’re thinking about switching, it pays to do it properly. Changing technology provider isn’t hard if you follow an order: first secure what’s yours, then understand what you have, and only then hand over.

How to tell a rough patch from a relationship that isn’t working

The difference is repetition: a rough patch is a one-off, while a failing relationship repeats the same problems for months. Every provider has bad weeks: someone off sick, a project that gets complicated, another client’s emergency. That’s normal friction, and a conversation usually sorts it out.

The serious signs look different:

• Deadlines always slip, and nobody explains why.
• Quotes grow even though what you asked for hasn’t changed.
• Answers arrive in language you don’t understand.
• Every fix breaks something else.
• Only one person knows how everything works, and when they’re away, everything stops.
• You don’t know where your code lives or who holds the keys.

The real cost isn’t just money. It’s the order you can’t take because the system won’t handle it, the Monday report someone still builds by hand, and the decision you keep postponing because you’re not sure your software will cope. Before switching, talk honestly with your current provider. Sometimes reordering priorities is enough. If nothing changes, you have your answer.

What to secure before you say anything

Before you announce the change, make sure you have access to everything that keeps your business running: code, servers, domain, accounts, data, documentation and contracts. This isn’t about mistrust, it’s about prudence. You can start this week:

• The code. Ask for access to the repository, the place where the code and its history of changes are stored. It should sit in an account owned by your company, not only in the provider’s.
• The servers. The machines or cloud services where your application runs. Is the account in your name? Who pays the bill?
• The domain. The address of your website and your email. Check that your company is the registered owner.
• Service accounts. The payment gateway (the service that takes card payments), email sending, app stores and other outside tools. Note who administers each one.
• Data and backups. Customers, orders, invoices, delivery notes. Check that backups exist and that you can download them.
• Documentation. Even if there’s very little, any note on how something is installed or updated is worth a lot.
• Contracts. Go through them with your adviser: who owns the code, and what do they say about ending the relationship and handing things over? Better to know now than halfway through.

If anything sits only in the provider’s name, ask for it to be moved to your company. Frame it as what it is: housekeeping.

Get an independent review of what you have

An independent review tells you the real state of your software before you decide what to do with it. Someone unconnected to your current provider looks at the code, the servers and how everything is set up, and explains it to you without jargon.

It answers concrete questions. Can what I have be maintained, or does it need rebuilding? Are there security risks? Am I paying for more servers than I need? Which parts are fragile? The conclusion might be that your system is fine and just needs tidying up, which saves you rebuilding something that works.

Be wary of anyone who tells you to throw everything away and start again before they’ve looked at anything. Rebuilding a system is expensive and risky, and it’s rarely the sensible first move.

How to run the handover calmly

A handover goes best when it’s planned, gradual and cordial. Your current provider knows the system better than anyone, and a few weeks of their cooperation is worth more than any document.

A sensible order:

1. Share the decision in person, respectfully and without blame. Explain that you want a different way of working, not a culprit.
2. Agree a transition period with clear dates and tasks.
3. Ask for sessions where the outgoing provider walks the incoming one through the system.
4. Change passwords and access once the handover is complete, not before and not in a rush.
5. Keep the system running throughout. No big changes during the transfer.

Your provider also has a business to look after. Treating them well isn’t just good manners: it makes a smooth handover more likely.

What to look for in your next technology partner

Your next technology partner should speak your language, be transparent and understand your business before touching the code. Technical skill is a given. What makes the difference is how they work with you.

Look for:

• Plain language. If you don’t understand them in the first meeting, you won’t later either.
• Transparency. They tell you what they’ll do, what it costs and what could go wrong. And they tell you when something isn’t worth doing.
• Interest in your business. They ask about your orders, your customers and how your team works before proposing anything.
• Continuity. Nothing depends on a single person, and everything is documented and in your name.

Mistakes to avoid

The most expensive mistakes when switching provider are the ones that leave you without access or without information. Watch out for these:

• Announcing the change before you have access to everything.
• Ending the relationship straight after an argument.
• Choosing the next provider on price alone.
• Using the switch as an excuse to rebuild everything without first reviewing what you have.
• Leaving nothing in writing: no list of access, no agreements, no dates.

How we approach it at vitamina.dev

At vitamina.dev we start by understanding your business and reviewing what you have, with no prejudice about who built it. We explain the state of your software in plain language, put access and documentation in order, and tell you what’s worth changing and what isn’t.

Our team has experience with commercial and business systems, fintech platforms, e-commerce and infrastructure, and knows that a good handover starts with not breaking anything. Once it’s done, we stay on as your trusted technical team, so your business never again depends on someone who doesn’t know it.

Frequently asked questions

Do I own the code my provider built for me?

It depends on what your contract says, so the first step is to review it with your adviser. If the contract says nothing, agree it in writing with your provider before you start the switch. Either way, ask for a complete, up-to-date copy of the code.

How long does it take to switch technology providers?

It depends on the size of the system, how much documentation exists and how much the outgoing provider cooperates. What matters isn’t speed but keeping your business running throughout. Ask your new provider for a plan in stages, not just an end date.

Do I have to rebuild my software if I change provider?

Not necessarily. Start by reviewing the state of what you have. If it works and can be maintained, the sensible choice is to tidy it up and improve it step by step. Rebuilding only makes sense when the system is holding your business back and fixing it would cost more than starting again.