Can you change your ERPNext implementer or support provider without starting over? Yes. ERPNext is open source and runs on any server, so your system is not locked to the company that set it up. What you need before you switch is access and copies in your own hands. This guide lists them, gives the order to switch in, and covers the cases that make a handover harder.
Short answer
Yes, you can change provider without starting over. First get the Administrator login, the server or Frappe Cloud account in your company's name, a recent backup with files and the encryption key, restored once on another server, and every custom app in a git repository you own. Then tell the old provider, and let the new one read the system before it changes anything.
The time to collect your keys is while the old provider still answers your calls. I lead ERPNext and Frappe programmes at MithTech, a team of Frappe specialists in Bengaluru. We take over ERPNext systems that other teams built, so we see what goes missing in a handover. The checklist below works whoever you move to.
Can you change your ERPNext provider without starting over?
Yes. ERPNext is open source under the GNU GPL version 3, so any provider can run, support and upgrade your system, provided you have access and your custom code. The licence is in the ERPNext repository itself (ERPNext licence). Nothing in it ties your site to the company that installed it.
What does tie you is practical, not legal:
- Access. If only the old provider can log in to the server, you cannot hand it to anyone.
- Custom code. If your custom apps live only on their laptop or in their private repository, the new provider starts blind.
- Knowledge. If nobody wrote down what was customised and why, the first weeks go on finding out.
The buyer objections guide touches on what happens when an implementer disappears. This post is the full handover.
What must you have in hand before you tell them?
Seven things: the Administrator login, the server or Frappe Cloud account, the domain, a backup that restores, the encryption key, the custom code and the list of integrations. Collect them first, quietly and politely, as part of normal good practice.
The Administrator login
Make sure your company holds the ERPNext Administrator password and at least one System Manager user in a named employee's name, not only the provider's.
The server or Frappe Cloud account
If ERPNext runs on your own server or cloud account, get root or SSH access in your company's name. If it runs on Frappe Cloud, the account that owns the site should be yours, with the provider added to it, not the other way round.
The domain and DNS
Check who controls the domain your ERPNext uses, and the DNS records that point it at the server. If the domain sits in the provider's name, moving the system gets harder.
A recent backup, with files, restored once
Ask for a full backup: the database plus public and private files. On a bench server the command is bench --site <your-site> backup --with-files (bench backup reference). Then restore it on a different server and open a few invoices. A backup you have not restored is a hope, not a copy.
The encryption key
Every Frappe site has an encryption key in its site config, used to encrypt saved passwords such as email accounts and integration keys. Frappe's docs say that when you restore a backup elsewhere, this key must be copied into the new site's config to keep using those passwords (Frappe Cloud docs). Ask for the site config file with the backup.
Every custom app, in a repository you own
Custom apps are code installed alongside ERPNext. They are not in the database backup. Ask for each one in a git repository that your company owns, with its full history.
The list of integrations and customisations
List what connects to ERPNext (payment gateways, e-invoicing, a website, WhatsApp, a bank feed) and where each key is set. Ask for a written list of customisations: custom fields, scripts, print formats and workflows.
Custom fields, client scripts, server scripts and print formats made in ERPNext's own screens are stored in the database, so they come with the backup. Custom apps do not. That is why the repository matters more than anything else on this list.
Who owns the custom code?
Your contract decides, not ERPNext's licence. Read what it says about ownership of work done for you, and ask for the repositories either way. The GPL governs how ERPNext itself may be used and shared; it does not settle who owns the custom app a provider wrote for you. This is a question for your contract and, if it is unclear, your lawyer. We cannot give legal advice.
In practice, asking early and plainly gives a handover its best chance. If the old provider will not hand over the repositories, you still have the database backup, so your data and your on-screen customisations are safe; only the custom apps need rebuilding or reworking.
What if ERPNext runs on the old provider's server?
Move it into your company's name before or during the handover: your own server, your own Frappe Cloud account, or a managed host that sets the server up in your name. A system on someone else's server can be switched off when the contract ends, however friendly the parting.
The move itself is a backup and restore:
- Take a full backup with files, plus the site config with its encryption key.
- Restore it on the new server at the same ERPNext version.
- Test it: log in, open recent invoices, run a report.
- Point the domain at the new server on a quiet day.
Which home to choose is its own decision. The guide to who runs ERPNext after go-live compares running it yourself, Frappe Cloud and a managed host, and says when running it yourself is the right answer.
What if you are on an old ERPNext version?
Then the new provider will plan an upgrade, one major version at a time, on a copy first. Frappe's support dates are:
| Version | Frappe support |
|---|---|
| Version 16 | To the end of 2029 (planned) |
| Version 15 | To the end of 2027 (planned) |
| Version 14 | Ended 31 January 2026 |
| Version 13 and older | No longer supported |
Source: Frappe supported versions, read 29 October 2026.
A change of provider is a good moment to plan the upgrade, but not to do it on the same day. Our support page sets out five steps, and they apply whoever does the work:
- Copy your live system onto a staging server.
- Upgrade one major version, never two at once.
- Test your custom apps, integrations and print formats against it.
- Rehearse: your team runs a normal day on staging.
- Go live on a quiet day, with a backup and a rollback plan.
What changed between versions 15 and 16 is in the v15 vs v16 guide.
How does the new provider take over?
A good new provider reads before it writes: your version, your custom code, your server and your backups, then a written plan. On our side, a takeover starts with a short call, then the first week goes on finding out what is there:
- Version and upgrade path: which version you run and how far it is from supported.
- Custom code: what is custom, where it lives, and whether it is in a custom app or edited into ERPNext itself.
- Server and backups: where it runs, and a backup restored to prove it works.
- Who answers: how you raise an issue, and how each one is tracked.
When custom code is heavy and the version is behind, cleaning up first is often cheaper than supporting the system as it is. Our ERPNext declutter audit does that, and support takes over a clean system afterwards.
Ask any provider you are considering to describe its first week in the same terms. If it wants to start changing things before it has read them, keep looking.
How do you choose the next provider?
Ask how they work, not only what they charge: response targets, how upgrades are tested, where your code will live, and what they hand back if you leave. The AMC and support cost guide explains how ERPNext support is sold, and the implementer comparison guide lists what to check.
Four questions sort providers quickly:
- Where will our custom code live? The right answer is a repository your company owns.
- How do you test an update before it reaches us? The right answer names a staging copy.
- What are your response targets, and in which hours? They should be written down.
- If we leave, what do we get? The same list as this post: logins, backups, the key and the code.
The last question tells you most. A provider that answers it calmly is one you are less likely to need to leave.
When should you clean up before switching?
When nobody knows what is custom, upgrades have been put off for years, or the numbers no longer tie out. In those cases, a new provider supporting the system as it is inherits the same problems. Our declutter audit reads the system first and fixes it in order of what costs you most. If the system itself is failing, not just the provider, the rescue guide covers how to tell what went wrong.
Frequently asked questions
+Does the old provider have to cooperate?
It helps a great deal, which is why you collect access and copies while relations are good. If you already hold the Administrator login, server access and a backup with the encryption key, a new provider can take over without them. Custom apps are the one part that is hard to recover without the old provider's repository.
+Can we change our ERPNext implementer in the middle of the project?
Yes, though it is harder than switching after go-live, because the new implementer must learn the scope, the data loaded so far and any half-built custom work. Get the signed scope, the current backup and the code repositories first. Then the new team reads what exists before agreeing a plan.
+Do we lose our data if the support contract ends?
Not if you hold a recent backup with files and the encryption key, restored once on another server. The data lives in the database, which is yours. The risk is a system on the old provider's server with no copy in your hands, so move it into your company's name first.
+Do we need Frappe's permission to change provider?
No. ERPNext is open source under the GNU GPL version 3, and anyone may run and support it. If you are on Frappe Cloud, the site belongs to the account that owns it, so check that the account is in your company's name and add or remove providers from it.
+How long does an ERPNext handover take?
It depends on what you already hold. With logins, a tested backup, the key and the code in hand, a new provider can start reading the system at once; we spend the first week of a takeover on version, custom code, server and backups. Missing pieces, and old versions, add time.
What is the bottom line?
Changing ERPNext provider is routine when your company holds the keys. Collect the logins, the server, a backup that restores, the encryption key and the custom code before you say anything, then let the new provider read before it changes a thing. If you are unsure what you hold, start with the handover board on our support page.
Thinking of changing provider?
Answer four questions about your version, server, builder and custom code. See what changes with a new provider, and book a free call if you want us to read it.
Comments & ratings
No comments yet. Start a new discussion.
Manoj · Published on 29 October 2026
Worked with us? Leave a Google review