You have probably already had this conversation with yourself. The support is not good enough, you know it is not good enough, and you have known for a while. What stops you is a specific picture: it is month end, something has broken, the new partner does not know your system yet, and the decision to move has your name on it.
That fear is reasonable. It is also the thing nobody writing about this will address honestly, because the standard promise is that the handover will be seamless, and seamless is not a plan. What follows is the version that treats you as someone with a real risk to manage, including the parts that are genuinely awkward.
The short version
A ByDesign support handover typically takes 4 to 8 weeks and does not touch your live system. You keep your tenant, your data, your configuration and your history, because SAP hosts the platform, not your partner. The work is knowledge transfer, not migration. The main risk is a gap in cover during the changeover, and that is a contract problem you can solve before you sign anything.
First, the thing everyone is worried about
Business ByDesign came off SAP’s price list for net new customers on 20 April 2026. That was widely misread as a shutdown. It was not. The change applies to new sales only, a distinction confirmed by independent coverage of the announcement, and the product has carried on shipping.
You can check that for yourself rather than take anyone’s word for it. The 26.08 release went live in August and included the updated German annual VAT return form for 2026, France-compliant e-invoicing through SAP DRC, Austria’s new 4.9% tax rate with the matching tax codes, and Form 131 for TDS certificates in India. That is a live product receiving current statutory compliance work, on a quarterly cycle.
Which raises a fair question. If your business trades in any of those countries, did anyone tell you?
What a handover actually involves
A support takeover is a transfer of knowledge and responsibility. Nobody reinstalls anything. In practice it has 5 parts, and they overlap rather than run in a neat line.
Discovery is the incoming partner learning your business, not just your system. What your month end looks like, which processes are load bearing, where the workarounds are, and which 3 or 4 things absolutely cannot break.
Access is the administrative work of getting the new partner properly provisioned in your tenant and registered with SAP for support routing, and getting the outgoing partner’s access removed on a date you choose.
Documentation is where the real value sits, and where most of the effort goes. Every customisation, every integration, every extension built in SAP Cloud Applications Studio, every scheduled job somebody set up in 2019 and forgot. If your current partner never documented this, the incoming partner has to reconstruct it, which is the single biggest variable in how long a takeover takes.
Parallel running means both partners are available for a defined window, so a question during cutover does not fall down a gap. This is the part that gets skipped when a switch is rushed, and it is the part that protects you.
Cutover is the day the new partner takes the tickets. It should be a non-event. If it feels dramatic, something earlier was skipped.
The week by week shape
Honest ranges rather than a single number, because the range is driven by how well your current setup is documented and how quickly your incumbent cooperates. A well-documented system with a professional handover sits at the fast end. A heavily customised tenant with an unhelpful incumbent sits at the slow end, or beyond it.
| Stage | Typical timing | What happens | What you need to do |
| Discovery | Weeks 1 to 2 | Process walkthroughs, review of open tickets and known issues, agreement on what must not break | Make 2 or 3 people available for a few hours each |
| Access and provisioning | Weeks 1 to 3, overlapping | New partner provisioned in your tenant, support routing updated with SAP, removal date set for the incumbent | Approve access, confirm who authorises what |
| Configuration documentation | Weeks 2 to 5 | Customisations, integrations, extensions and scheduled jobs recorded and verified | Point them at anything undocumented you know about |
| Parallel cover | Weeks 4 to 6 | Both partners contactable, new partner shadows live tickets | Route new tickets to the incoming partner, keep the old route open |
| Cutover | Week 6 to 8 | New partner takes full responsibility, incumbent access removed | Tell your team who to contact |
| First release cycle | Next quarterly release | SAP deploys it automatically. This is the real test of whether your new partner proactively walks you through what changed and what it means for you | Ask your new partner to document and share what’s in each release before it lands |
Deliberately not on that list: any downtime. A support handover does not require an outage, because nothing about the running system changes.
What stays with you
This is where the reimplementation myth needs killing, because it is the belief that keeps people stuck.
Your ByDesign tenant is not your partner’s. It is delivered as a service, and as SAP’s own technical documentation puts it, SAP handles application maintenance and upgrades, innovations, data storage, and security. Your partner sits alongside that arrangement. They configure, support and extend your system. They do not host it and they do not own it.
So your data stays. Your configuration stays. Your customisations stay. Your transaction history, your master data, your reports, your integrations, all of it stays exactly where it is. Switching support partner is closer to changing your accountant than to moving house.
The exception worth checking is anything your current partner built and licenses to you as their own intellectual property, rather than something built inside your tenant. Partner-built extensions sold through the SAP Store are supported by the partner who built them. If you have any, ask now what happens to them if you leave, because that is a commercial question with a real answer and you want it before you commit rather than after.
The contract questions to ask before you commit
Read your existing agreement first and get your own legal adviser to look at anything that concerns you. Three things are worth finding.
Your notice period, and the date it has to be served by. Some agreements auto-renew for a further 12 months unless notice lands in a specific window, and missing that window by a week is an expensive mistake that has nothing to do with the quality of your decision.
What your incumbent is obliged to do on exit. Many ERP support contracts are quiet on handover cooperation, which means it becomes a goodwill matter at exactly the point goodwill is in short supply. If yours is silent, expect to negotiate rather than instruct.
What happens to your data. This one is stronger than most people realise. Where your partner processes personal data on your behalf, UK GDPR requires specific terms in the contract, and the ICO’s guidance is explicit that under Article 28(3)(g) the contract must say that at the end of the contract the processor will, at your choice, delete or return all the personal data it has been processing for you, and delete existing copies unless UK law requires otherwise. Article 28(3)(h) goes further and requires the processor to give you the information needed to show those obligations have been met. That is a legal position, not a favour you have to ask for nicely.
What to get in writing before you sign with anyone new: the handover plan with dates, who carries the risk during parallel running, what happens if documentation turns out to be worse than expected, and what the first quarterly release looks like under the new arrangement.
What good looks like on day one
Not software. You already have the software. What changes is capability.
You should have named people who know your configuration, rather than a queue. You should be told what is in the next quarterly release before it lands, with a view on which parts matter to you and which you can ignore. Small changes should be handled inside your agreement rather than returned as a quote, which is the difference a fixed-price model makes to the conversation. Support hours should cover your month end rather than someone else’s office hours.
You should also expect a straight answer on the bigger question, which is when and whether you eventually move to SAP Cloud ERP. That decision is real and it is coming for most ByDesign users, but it belongs on a roadmap you control rather than arriving as a rumour. We have written separately about what that move actually involves. A partner who cannot help you think it through is telling you something useful about the depth of their bench.
Where Codestone comes in
We are an SAP Gold Partner and we run ByDesign support on a fixed-price model with 24/7/365 cover, which means change requests are a conversation about priority rather than a conversation about invoices. We have taken over systems that were poorly documented and systems that were documented well, and the honest difference between them is a few weeks of discovery, not a different outcome.
If you want to know what a takeover would look like for your setup specifically, that is a short conversation and it costs nothing.
