Back to Blog
How to Switch SAP Business One Partners: What Moves, What Doesn't, and How Long It Takes
14 September 2026•Susan Woolley•SAP Business One

How to Switch SAP Business One Partners: What Moves, What Doesn't, and How Long It Takes

Switching SAP Business One partners means transferring your licence relationship and support contract from your current partner to a new accredited one - and, in most cases, moving your hosting at the same time. It is not a reimplementation, a data migration project or a new system. SAP Business One is sold and supported through a partner network, and SAP's model allows a customer to move between accredited partners.

That distinction is the whole reason this article exists. Most businesses that are unhappy with their partner never investigate switching because they picture the disruption of their original implementation. The reality is a much smaller, much more contained exercise - and once you can see exactly which parts move and which don't, the decision stops being frightening and becomes a straightforward piece of due diligence. Here is the honest anatomy of a partner switch: the three things that transfer, the long list of things that stay exactly as they are, the sequence a well-run handover follows, and what genuinely determines the timescale.

Quick answer

Three things move when you switch SAP Business One partner: your licence relationship, your support contract and - if you choose - your hosting. Everything else stays exactly where it is: your database, your configuration, your customisations, your add-ons and the way your team works. The handover runs in a set order - review, commercial transfer, then a planned and tested cutover if hosting is moving - and is typically measured in weeks, with any downtime concentrated into an agreed window scheduled around your business calendar.

 

What moves: three things, and only three

1. Your licence relationship

Your SAP Business One licences were bought for your business, but they are administered through a partner. When you switch, the new partner becomes the one that manages your licences with SAP - renewals, maintenance, adding users as you grow. Nothing about the licences themselves changes. What changes is who looks after the paperwork and, importantly, who advises you on it. A partner paying attention will often find licence positions that no longer match how the business actually works - user types that could be better matched to what people really do, for example - because nobody has reviewed them in years.

2. Your support contract

This is usually the reason for the whole exercise. Your support agreement with the outgoing partner ends - subject to whatever notice period your contract specifies, which is worth checking early - and a new agreement begins with the incoming one. From your team's point of view, this is the visible change: a different number to call, different people answering it, and, if you have chosen well, a very different experience when they do. Before the switch date, a competent incoming partner will have already reviewed your system, so the first support call is not the first time they have seen your setup.

3. Your hosting - if you want it to

Hosting is the optional third mover, and the one that varies most. If your system runs on-premise or with a hosting arrangement you are happy to keep, a partner switch can leave it untouched. In practice, though, hosting is often part of the problem: ageing servers, patchy backups, or a platform bolted together by a partner whose real trade is implementation rather than infrastructure. In that case the switch is the natural moment to move SAP Business One onto a purpose-built cloud platform. That part of the move is a planned migration - copied, tested, verified and then cut over at an agreed time - and it is the piece that adds most of the elapsed time to a switch.

What doesn't move: everything your business runs on

Now the longer and more important list. Your database does not move in any way your users would notice - every customer record, supplier, item, price list, open order and year of transaction history is preserved, because it is your data sitting in your system. Your configuration stays: the workflows, approval rules, document layouts and user settings shaped around how your business operates. Your customisations and add-ons stay, because they live inside your system, not the outgoing partner's office. And your people's knowledge stays - same screens, same processes, same shortcuts they have used for years. There is no retraining burden, because there is nothing new to learn.

This is worth dwelling on, because it is the exact inverse of what most people fear. The instinct is to assume that changing partner puts the system at risk. In fact the system is the stable element throughout; the only things that change are commercial relationships wrapped around it. The one caveat worth knowing: if your current setup includes undocumented customisations - changes made over the years that nobody wrote down - a good incoming partner will surface and document them during the takeover review. That is not a risk created by switching; it is a risk you already have, being fixed.

The handover, step by step

Every well-run takeover follows the same broad sequence, whatever the size of the system. It starts with a review: the incoming partner examines your configuration, customisations, add-ons, integrations, licence position and data quality. This serves two purposes - it lets them price support honestly rather than guessing, and it surfaces anything undocumented before it can cause a surprise later. Expect to give them access to the system and an hour or two with the people who know it best; expect them, in return, to produce a clear picture of what they are taking on and a written plan for the move.

Next comes the commercial transfer: notice served under your existing support agreement, the licence relationship moved to the new partner, and the new support arrangement signed with service levels you can hold them to. If hosting is staying put, the switch is essentially complete at this point — support simply goes live with the new team on the agreed date. If hosting is moving, the migration runs as its own planned workstream: the system is replicated onto the new platform, tested thoroughly against the live environment, and then cut over in an agreed window - typically outside working hours, and never during month-end or your seasonal peak. Your team logs off the old platform and logs into the new one, with everything exactly where they left it.

Two things should be true throughout, and are worth demanding in writing: a named plan with responsibilities and dates, and a rollback position for the cutover itself, so that if anything unexpected appears during the switch window, the business carries on while it is resolved. A partner who has done this many times will offer both before you ask. Our full guide to changing SAP Business One partner covers how to evaluate the partner doing the taking over - this article assumes you have chosen one worth moving to.

How long it really takes

The honest answer is weeks, not months - but which number of weeks depends on three drivers, and a trustworthy partner will tell you which apply to you rather than quoting one figure for everyone. The first is whether hosting is moving. A support-and-licence transfer on its own is largely an administrative exercise paced by your notice period; add a cloud migration and you add the replication, testing and cutover work. The second is complexity: a heavily customised system with several add-ons and integrations needs more review and more testing than a clean one - not because anything is being rebuilt, but because everything must be verified working on the new platform before anyone relies on it. The third is your calendar. Sensible switches are scheduled around the business - after year-end, ahead of peak season - and that scheduling often shapes the elapsed time more than the technical work does.

One driver sits outside everyone's control except yours: the notice period in your current support contract. Check it before anything else. It sets the earliest realistic switch date, and knowing it early lets the incoming partner plan the takeover to land the moment you are free - rather than leaving a gap, or paying two partners at once for longer than necessary.

What can slow a transfer down (and how to avoid it)

Most delayed transfers trip over the same few stones, and all of them are avoidable with early attention. Undocumented customisations are the most common: if the outgoing partner built things nobody recorded, the review takes longer - so grant system access early and dig out whatever documentation exists, however thin. Contractual friction is the second: notice periods, auto-renewal clauses and, occasionally, an outgoing partner slow to cooperate. Read your agreement before you signal anything, and let the incoming partner guide the sequencing - they have seen every version of this before. The third is timing collisions: trying to cut over near month-end, year-end or peak trading compresses testing and raises stress for no benefit. Give the move a calm window and the whole exercise is, for most of your business, a non-event - which is precisely the goal.

What switching costs

Transferring SAP partner doesn't cost anything - the support and maintenance of your solution simply transfers to another partner for the licences you have, or are already paying a subscription for. When you move your system to Ascarii's cloud platform, it is likely to be more competitive that your current supplier, simply due to Ascarii's AWS status and inclusive support offered. Our extensive experience with SAP Business One hosted on AWS means that we're experts in sizing the cloud resources businesses need to ensure they don't pay more than they need to.

Where Ascarii fits

Ascarii takes over SAP Business One systems from other partners as well as implementing new ones. We are an SAP Premier Partner and AWS Advanced Tier Services Partner, 100% dedicated to SAP Business One, with 15+ years of experience and a 4.9 out of 5 customer satisfaction rating. Systems we take on move onto our cloud platform, running SAP Business One on AWS with 99.995% uptime - and the handover follows exactly the shape described above: review first, plan in writing, cut over around your calendar.

If you are weighing a switch, the useful first step costs nothing: a conversation about your current setup, your contract position and what a move would actually involve for your business. Book a discovery call - and if the honest answer is that you should stay where you are, that is the answer you will get.

Frequently asked questions

Do we need our current partner's permission to switch?

No. The choice of partner is yours, and SAP's partner model allows customers to move between accredited partners. You do need to respect the notice terms in your existing support contract, so read it early - but the decision itself does not require the outgoing partner's approval, and a professional incoming partner will manage the sequencing for you.

Will there be downtime when we switch?

If only support and licences are moving, no - your system carries on untouched. If hosting is moving, the downtime is confined to a planned cutover window, agreed in advance and normally scheduled outside working hours, with the system tested on the new platform before anyone relies on it and a rollback position agreed in case of surprises.

Can we switch partner in the middle of a support contract?

Usually the practical constraint is your notice period rather than the contract's end date - many agreements allow termination with notice, while some run to a renewal date. Check the agreement before signalling anything, and share it with the incoming partner: sequencing the switch around your contractual position is a normal part of the takeover plan.

Will our add-ons and integrations still work after a switch?

Yes - they are part of your system and move with it. Where hosting is changing, every add-on and integration is tested on the new platform before cutover, which is one of the main jobs of the takeover review. It is also common for that review to surface add-ons that are outdated or no longer used, which is useful housekeeping rather than a risk.

Does switching partner affect our SAP Business One version or licences?

Not by itself. Your licences transfer as they are, and your system stays on its current version through the switch. Once support has moved, a good partner will review whether your version and licence mix still fit the business - but any upgrade is a separate, planned decision made with you, never a hidden part of the handover.

How long does a SAP Business One partner switch take?

Typically weeks rather than months. A support-and-licence transfer is paced mostly by the notice period in your current contract; adding a hosting migration adds replication, testing and a planned cutover. Complexity and your business calendar shape the rest - a trustworthy partner will give you a timeline after reviewing your system, not before.