SAP Business One customers buy their licences, maintenance and support through a partner. Most of those relationships work well for years. Some do not: the consultant who knew the system leaves, support slows down, or an implementation stalls halfway through. When that happens, many companies assume they are stuck. They are not. Changing partners is a routine, documented process, and your system, data and customizations stay yours throughout.
Signs it is time to look
The reasons we hear most often are practical rather than dramatic:
- Support requests take days to get a first response, and most responses are a quote.
- The implementation has missed its go-live date more than once and nobody owns the plan.
- Customizations were built over the years and nobody can explain what they do.
- The partner no longer has anyone who understands your industry.
- Upgrades keep being postponed because nobody is confident they will work.
Any one of these is worth a conversation. Several together usually mean the cost of staying is higher than the cost of moving.
What actually changes
Changing partners does not mean reinstalling SAP Business One or re-implementing it. The database, the documents, the customizations and the user setup all stay where they are. What moves is the relationship: who supports the system, who holds the maintenance, and who you call.
Maintenance and support are transferred through a formal process with SAP. Your new partner coordinates it with you, and with your current partner where needed. It is worth reading your current agreement first for notice periods or renewal dates, so the timing works in your favour.
Step 1: a first conversation
Before anything formal happens, talk to the prospective partner about what is not working, what must keep working and what you expect from the next relationship. A good partner will ask about your processes as much as your software, and will tell you plainly if moving is not worth it.
Step 2: a system audit
The single most important step is an audit, ideally on a copy of your company so nothing is touched. It should cover:
- Version and environment: the SAP Business One release, Microsoft SQL Server or SAP HANA, where it is hosted, how it is backed up and what the upgrade path looks like.
- Customizations: user-defined fields and tables, formatted searches, approval procedures, queries, print layouts and Crystal Reports.
- Add-ons and integrations: every third-party add-on, every piece of custom code and every connection to another system, and whether each uses supported interfaces.
- Data quality: items, business partners, price lists and open documents, and the inconsistencies behind daily workarounds.
- Users and security: licences, roles and who can change what.
- Open issues: the problems your team works around today, collected from the people who use the system.
The output should be written: what was found, what is at risk, and a prioritized plan of what to fix now, what to improve later and what to leave alone.
Step 3: the handover
With the audit done, the formal transfer of maintenance and support goes ahead. Credentials, documentation and access to any hosted environment move across. A careful handover is invisible to your users: the system keeps running, and the only thing they should notice is faster answers.
Step 4: stabilize, then improve
The first weeks should go on urgent fixes from the audit, not on new projects. Once the system is stable, the improvements that were waiting can be planned and delivered under one support agreement, with one team accountable.
Rescuing a stalled implementation
If the move happens mid-project, the audit matters even more. It establishes where the project really stands: what is configured, what was migrated, what was tested and what was promised. Only then should anyone agree a new plan and a new go-live date. Starting configuration again before that is understood is how a stalled project becomes a failed one.
Questions to ask a new partner
- Who will actually work on our system, and can we speak to them before signing?
- How do support requests reach someone, and what happens out of hours?
- How do you document customizations, and will we get a copy?
- How do you approach upgrades, and do you rehearse them on a copy first?
- Do you build integrations only on supported interfaces?
- What happens if we want to leave you one day?
The last question is a good test. A partner who answers it comfortably is usually one you will not want to leave.
Talk to us about switching or read about changing your partner for SAP Business One.