When (and How) to Switch Your Business Central Partner

If your Business Central partner takes three days to answer an email, bills you £350 to add a single field to a page, and has never once mentioned the upcoming release wave — you already know something’s wrong. What you may not know is how straightforward it is to leave.

Switching your Business Central partner isn’t the nightmare people imagine. No data loss. No re-implementation. No starting over. Microsoft’s ISV model and Business Central’s cloud architecture mean your system, your data, and your licenses are yours — the partner is a service provider you can change, like any other.

This article walks through exactly when to make the call, what switching actually involves, and how to land with a partner who treats your business like it matters. From a team that’s been on the receiving end of those calls more times than we can count.

---

The Warning Signs: 10 Signals Your Partner Isn’t Working

Not every frustration means you need a new partner. But some patterns aren’t fixable — they’re structural. Here are the signs that it’s time to move on.

1. Response times are measured in days, not hours

If support tickets sit for 48–72 hours without acknowledgment, the partner is either understaffed or doesn’t prioritize your account. In a live Business Central environment, a blocked sales order or a posting error needs attention today — not “we’ll look at it next week.”

A functioning support relationship has an SLA. Something like: critical issues acknowledged within 2 hours, resolved within 8; standard issues acknowledged within 8 hours, resolved within 48. If you don’t have that in writing, you don’t have support — you have hope.

2. They’re invisible between release waves

Microsoft drops two major Business Central release waves every year — Wave 1 in April, Wave 2 in October. Each brings new functionality, deprecated features, and changes that affect your system. If your partner never reaches out before a release wave to say “here’s what’s coming, and here’s what it means for you” — they’re not doing their job.

Proactive partners run a pre-wave review: they scan your extensions, identify deprecated objects, test critical flows in a sandbox environment, and brief you before the wave hits. Reactive partners wait for you to discover that something broke.

3. You’re always billed for “scope creep” on basic tasks

Adding a field to a page card or creating a simple report isn’t a change request — it’s support. If every minor adjustment triggers a separate invoice and a scope discussion, the partner’s business model is billable hours, not client success.

Reasonable partners draw a clear line: support requests (fixing issues, minor configuration, adding fields to existing pages, adjusting reports) fall under your support agreement. New development (an entirely new module, a custom integration to a third-party system, new AL extensions) is billable. If everything is billable, you’re not a client — you’re a revenue stream.

4. They can’t explain how your own system works

When you ask “how does our approval workflow handle exceptions?” or “what happens when a purchase receipt is posted with a cost variance?” — a partner who knows your system can answer from memory. A partner who says “let me check and get back to you” every single time doesn’t understand your implementation well enough to support it.

This matters because Business Central isn’t a generic SaaS product where “best practice” covers 90% of cases. Every implementation is configured to that company’s processes. A partner who doesn’t know yours is guessing.

5. Nobody can write AL — or the only developer who could has left

Business Central extensions are written in AL. If your partner’s technical team consists of one person who left six months ago and nobody replaced, your custom functionality is frozen. You can’t upgrade extensions, fix bugs in your custom code, or build new features.

Ask directly: “Who writes AL on your team, and how many AL developers do you have?” If the answer is evasive, or you recognize the name as the person who left, you already know.

6. Your partner has never once pushed back

A partner who says “yes” to everything is more dangerous than one who says “no” sometimes. If you ask for a customization that duplicates standard Business Central functionality, a good partner tells you. If you want a process flow that contradicts core system logic, a good partner explains why and suggests an alternative. A partner who just bills you for whatever you ask for isn’t an adviser — they’re a body shop.

7. They haven’t mentioned AppSource in the last year

Business Central’s AppSource marketplace has thousands of certified extensions — pre-built solutions for industry-specific needs. A partner who recommends custom development for something AppSource solves for £50/month is either unaware of the ecosystem or incented to bill development hours. Either way, you’re paying for it.

8. You don’t have a named account manager or support contact

If every support request goes to a generic email address, and the person who responds is different every time — nobody owns your account. There’s no institutional knowledge, no relationship, and no accountability. You’re in a queue.

9. Month-end close support is a coin toss

Month-end is when ERP problems surface. If your partner is unreachable during the last three days of the month — or worse, charges premium rates because they know you’re stuck — you don’t have a partner. You have a vendor who shows up when convenient.

10. Your team actively avoids contacting them

This is the quietest sign and the most damning. When your finance controller would rather spend an afternoon building an Excel workaround than send a support ticket — your partner has already lost. Trust eroded to the point where the system’s primary users have given up on getting help.

---

”Is It the Partner, or Is It Us?” — An Honest Self-Assessment

Before you fire your partner, do the uncomfortable thing and check whether the problem is on your side. We’ve seen companies switch partners, burn through the transition, and land in the same situation six months later — because the root cause was internal.

Run through this checklist honestly:

• Do we have a dedicated project lead or system owner? Someone whose job explicitly includes managing the BC relationship and internal priorities. If nobody owns the system internally, no external partner can succeed.
• Have we defined clear SLAs with our current partner? If you’ve never agreed what “responsive support” means, it’s hard to hold them to it. Did you sign a support agreement with specific response times, or just a handshake?
• Do we respond when the partner needs something from us? If your partner asks for a decision or a data sample and waits two weeks, the relationship isn’t one-sided. Slow clients create slow partners.
• Are our requests realistic? Demanding a complex AL extension in three days or expecting a partner to know your undocumented, custom-built Excel-to-legacy-system integration process isn’t fair.
• Have we communicated our frustrations directly? Before assuming the partner doesn’t care — have you told them? A frank conversation (“here’s what’s not working, and here’s what we need to change”) sometimes fixes things.
• Are we paying appropriately? If you negotiated a rock-bottom support contract with no minimum commitment, the service level you’re getting may simply match what you’re paying. A £150/month support retainer doesn’t fund a dedicated consultant.
• Is the team using the system? If half your staff still runs the business on spreadsheets and shadow IT, and the partner’s work is being ignored — that’s not a partner problem.

If you’ve checked most of these boxes and the partner is still falling short on the 10 warning signs above — the problem is them.

If you haven’t checked many — fix the internal issues first. Otherwise you’ll bring the same problems to the next partner, and nobody wins.

---

What “Switching Partner” Actually Involves

This is where most people get anxious, so let’s demystify it. Switching your Business Central partner is not a re-implementation. It’s an administrative handover with a knowledge transfer. Here’s exactly what changes and what doesn’t.

What stays the same

• Your Business Central tenant. The same URL, the same environment. Nothing gets migrated or rebuilt.
• Your data. All transactions, master records, configurations — untouched.
• Your Microsoft licenses. Your relationship is with Microsoft, not the partner. Licenses continue uninterrupted.
• Your extensions. Any AppSource extensions you’ve installed remain. Custom AL extensions stay — the source code should be in your tenant or the partner’s repository.

What changes

• Partner of Record. Admin action: a Microsoft Partner Center relationship is created with the new partner. Your old partner is removed as the delegated admin.
• Support. Your tickets go to a new team. The new partner needs to understand your system — that’s the knowledge transfer phase.
• Development ownership. If your old partner built custom AL extensions, you need the source code and symbols. This is the single most important thing to verify before initiating a switch.
• Billing. Your support and development agreements move to the new partner.

The one thing that can go wrong: extension source code

Custom AL extensions built by your previous partner live in their development environment and their source control. If the partner owns the IP and hasn’t transferred it to you, or if they deliver only compiled .app files without source, a new partner can’t modify those extensions.

Before you tell your current partner you’re leaving, verify:

• Do you have the full AL source code for every custom extension in your tenant?
• Are those extensions published with a scope that allows another partner to manage them?
• Is the IP ownership clear — who owns the extensions they built?

If you don’t have source code, your new partner can often decompile and reconstruct it, but it adds cost and time. For critical extensions, budget 5–15 extra consulting days if source code isn’t available.

This is why you don’t announce a switch until you’ve secured these assets. Once the relationship is severed, getting source code from an unhappy former partner is harder than it should be.

---

How to Evaluate a New Partner

You’ve decided to switch. Now the question: how do you avoid landing in the same situation? Here are the criteria that actually matter — beyond the sales deck and the reference call.

1. AL extension ownership and development capability

Ask: “When you build custom extensions for us, who owns the IP?”

The right answer: “You do. The code goes into your repository. We build it, you own it.” If the answer is vague about IP, or the partner considers their extensions proprietary, walk away. You’ll be trapped with them again. Our support and upgrade services are built on this principle — our clients own their extensions, always.

Also ask how many AL developers they have, and whether you can meet the person who’d handle your account. If they can’t name the developer, they’re a sales organization, not a delivery organization.

2. Response time SLA — in writing

A verbal commitment to “respond quickly” is meaningless. Ask for a written SLA with:

• Critical (system down, cannot post): Response within 1–2 hours, resolution target within 4–8
• Standard (feature not working, process blocked): Response within 4–8 hours, resolution within 24–48
• Minor (cosmetic, nice-to-have): Response within 24 hours, resolution within agreed timeframe

Ask what happens if they miss the SLA. A partner with a penalty clause — even a modest one — is a partner who takes their commitments seriously.

3. Proactive advisory, not just reactive support

Ask: “What do you do between support tickets?”

A real partner has an answer: pre-release wave reviews, quarterly health checks, adoption monitoring, optimization recommendations. They mention things you haven’t thought of — Copilot features you’re not using, AppSource extensions that could replace an expensive manual process, performance tuning that would cut your month-end close time.

A ticket-jockey says: “We respond to your requests.” That’s not enough. One of the most common reasons companies reach out for a partner switch is that the current partner never brings new ideas to the table.

4. Cultural fit and communication style

This sounds soft, but it’s hard-edged in practice. Ask:

• What does their typical communication cadence look like? Weekly check-ins? Monthly reviews? Only when you reach out?
• Do they communicate in plain business language, or is everything wrapped in consultant-speak and acronyms?
• When something goes wrong — a missed deadline, a bug, a miscommunication — how do they handle it? You want a partner who owns mistakes directly, not one who deflects.

Geography matters here too. A partner in a vastly different time zone means your urgent tickets land at 2 AM their time. A partner who has never worked in your country may not understand local compliance, VAT regimes, or business norms. Vanguard 360 operates across Europe, the UK, the UAE, and Saudi Arabia — because in practice, a partner who understands your regulatory environment saves you compliance headaches that are invisible during the sales process.

5. Case studies and references in your industry

Same rule as choosing an implementation partner: ask for references from companies in your industry, of your size. A partner with 15 manufacturing clients understands production orders and routings. A partner who’s only ever done professional services implementations will struggle with your warehouse configuration.

Ask: “What’s the most recent company you onboarded from another partner, and can I speak to them?” A partner who has handled multiple switches has a process for it. A partner who has never done one will learn on your time.

6. The overlap process — how they handle the transition

Ask them to walk through exactly how they handle a partner switch. Details to listen for:

• Do they do a formal system audit before taking over? (They should — you don’t want a partner who takes over blind.)
• What’s their knowledge transfer process? Who documents what?
• How do they handle the overlap period when both partners have access?
• If the outgoing partner is uncooperative, what’s the fallback?

A partner who can’t articulate this process hasn’t done it enough. A partner who can walk you through it in detail has.

---

The Transition Process: How a Switch Typically Goes

Here’s what a partner switch actually looks like, week by week. This is based on real transitions — not theory.

Week 1: Discovery & Audit

The new partner gets access to your Business Central environment (you add them as a delegated admin in Partner Center — your old partner doesn’t need to be involved at this stage). They run a full audit:

• What extensions are installed, and are they from AppSource or custom-built?
• What’s the system configuration — chart of accounts, dimensions, posting groups, workflows?
• What integrations are active, and how are they configured?
• Are there any errors, performance issues, or technical debt visible?
• Is the environment current on updates?

At the end of this week, the new partner delivers an audit report: what’s working, what needs attention, what the transition plan looks like.

Week 2–3: Knowledge Transfer

This is the most variable phase. If your outgoing partner cooperates, you schedule 2–3 handover sessions: the outgoing partner walks the incoming partner through the system architecture, custom extensions, integrations, and open issues. The incoming partner documents everything.

If the outgoing partner is uncooperative — and, honestly, this happens — the incoming partner works from the audit, your internal documentation, and their own analysis of the system. It takes longer, costs more, and isn’t ideal, but it’s entirely doable. Business Central is a standard product with a transparent data model; a competent partner can figure it out regardless.

Your role during these weeks: Make your internal system owner available. They know things that aren’t written anywhere — why posting group 47 exists, what that custom report does, which integration breaks quietly every six weeks. This knowledge isn’t in the documentation; it’s in their head, and it needs to be transferred.

The “Scary Week”: When Your Old Partner Exits

At some point — usually week 3 or 4 — you remove the old partner’s delegated admin access in Microsoft Partner Center. They can no longer access your tenant.

For most companies, this is the moment of anxiety: what if something breaks and the new partner doesn’t know how to fix it?

The honest answer: the first week after the switch can be bumpy. Not catastrophic — Business Central doesn’t spontaneously combust — but bumpy. A user reports an issue the old partner always handled. An integration behaves unexpectedly. The new partner needs to trace through something that the old partner had memorized.

A good incoming partner plans for this. They have senior consultants on standby during the transition week. They over-communicate. They triage aggressively — anything critical gets a response within the hour.

By week two post-switch, things settle. By week four, the new partner knows your system as well as the old one did — often better, because they’ve just audited everything fresh.

---

Timeline and Cost of Switching

Timeline

Phase	Duration	Key Activity
Partner selection	1–3 weeks	Evaluate candidates, check references, negotiate terms, sign agreement
System audit	3–5 days	Incoming partner reviews your tenant, extensions, configurations, integrations
IP & source code check	1–5 days	Verify ownership of custom AL extensions; obtain source code from outgoing partner
Knowledge transfer	1–3 weeks	Depends entirely on outgoing partner cooperation; longer if they’re uncooperative
Partner handover	1 day	Remove old partner’s delegated admin access; new partner takes over
Stabilization	2–4 weeks	Intensive support as new partner learns your system in production
Total	4–8 weeks	From decision to stable state

Costs

Item	Estimated Cost	Notes
System audit	€1,500–3,000	One-time. A new partner may credit this against an ongoing support contract
Knowledge transfer	€2,000–8,000	Variable. Cooperative outgoing partner = lower end. Uncooperative = higher end
Extension source code (if missing)	€3,000–10,000+	Decompilation and reconstruction of custom extensions if source code unavailable
Transition support intensive period	Included in support contract	First 4 weeks typically require 2–3× normal support hours
Ongoing support	€500–2,000/month	Depends on complexity and SLA level. Our typical support contracts run €500–2,000/month depending on the number of users, integrations, and custom extensions
Total one-time switching cost	€3,500–21,000	Heavily dependent on the source code situation and outgoing partner cooperation

Compare this against the cost of staying with a partner who charges £350 for every minor change, takes three days to answer, and provides no proactive value. For most mid-market companies, the switch pays for itself within 6–12 months — not in direct cost savings, but in system improvements, faster issue resolution, and access to new Business Central features the old partner never surfaced.

If you’re also considering a broader Business Central implementation — for example, if you’re on an older NAV system and using the switch as a trigger to modernize — the timeline extends, but the logic of starting fresh with the right partner holds.

---

What Nobody Tells You About Switching

After handling partner transitions across multiple industries and countries, here’s what consistently surprises people:

1. Your documentation is almost certainly poor — and that’s normal

Most companies discover during a partner switch that their system has almost no documentation. Configuration decisions made years ago weren’t recorded. Custom extensions exist without comments. The integration between BC and the warehouse system works, but nobody documented how.

This isn’t a failure — it’s the natural result of a support relationship where knowledge lived in people, not in files. But it means the incoming partner’s first job is creating documentation from scratch. Budget for it. A 10–15 page system overview document — architecture, configurations, integrations, customizations — is one of the highest-value outputs of a partner switch.

2. Your old partner will probably be unhelpful about the handover

Some outgoing partners are professional. Most are not.

You’ve ended a revenue relationship. They’re being asked to spend time transferring knowledge to their replacement. The incentives are not aligned. Expect minimal cooperation, delayed responses, and “we don’t have time for a handover call this week.”

This is why you secure source code and any passwords, API keys, and environment access before announcing the switch. Once the relationship is formally ending, goodwill evaporates. The incoming partner should have a playbook for an uncooperative handover — and if they don’t, that’s a red flag.

3. Switching mid-implementation is fundamentally different from switching at steady state

If you’re in the middle of a Business Central implementation and the relationship has broken down — that’s a different playbook entirely. The incoming partner isn’t just taking over support; they’re inheriting an incomplete project. They need to:

• Understand the scope that was sold vs. the scope that was being delivered
• Assess what’s been built and whether it matches your requirements
• Rebuild trust with your team, who are probably exhausted and frustrated
• Potentially restart pieces that were built incorrectly

Switching mid-implementation typically adds 4–8 weeks to the project timeline and costs 20–40% more than completing with a single partner. But completing with a broken partner costs more in the long run — the system will have problems, your team won’t trust it, and you’ll switch later anyway, when things are more entangled.

If you’re mid-implementation and considering a switch, do it now, not after go-live. The earlier you cut losses, the less rework is needed.

4. The relationship with the new partner needs to be different from the start

Companies that switch partners and fall into the same patterns — minimal communication, no defined SLAs, no regular reviews — end up switching again. The switch is an opportunity to reset:

• Define SLAs in the contract, with specific metrics and review cadences
• Schedule quarterly business reviews — not just support ticket reviews, but strategic discussions about where your business is going and how BC can support it
• Treat the partner as an adviser, not a vendor. Ask for recommendations. Invite them into your planning conversations. The value of a BC partner isn’t in closing tickets — it’s in helping your business operate better.

---

Frequently Asked Questions

Can I switch Business Central partners without Microsoft’s involvement?

Yes. Microsoft is not part of the partner relationship. Your licenses are with Microsoft directly. The partner relationship is managed through Microsoft Partner Center, and you — as the customer — control who has delegated admin access. You add the new partner, remove the old one. Microsoft doesn’t need to approve the change.

Will my Business Central environment go down during the switch?

No. There’s no downtime. Switching partners doesn’t touch your tenant configuration, your data, or your user access. It’s purely an administrative change in Partner Center — who has delegated access to support your environment.

What happens to my custom extensions after the switch?

If you own the source code, the new partner takes it over — they review it, document it, and handle ongoing maintenance. If the old partner owns the source code and won’t provide it, the new partner needs to reconstruct or replace the extensions. This is the single biggest variable in switch cost and timeline. For our support and upgrades clients, we audit this immediately — before anything else.

How do I tell my current partner we’re leaving?

Professionally and directly. A brief call or email: “We’ve decided to move our Business Central support to another partner. We appreciate the work you’ve done. We’ll coordinate the handover in the coming weeks.” No lengthy explanation, no negotiation — you’ve made the decision. Keep it clean. The sooner it’s communicated, the sooner the transition begins.

Can I keep some services with my old partner while moving support?

Technically yes, but practically no. A split relationship — one partner for support, another for development, a third for licensing — creates confusion and finger-pointing. When something goes wrong, everyone blames everyone else. If you’re switching, switch completely. One partner, one relationship, one accountable party.

How long until the new partner knows our system as well as the old one?

A competent partner gets to 80% understanding within 2–3 weeks of intensive engagement — audit, documentation review, and knowledge transfer. The remaining 20% — the edge cases, the historical decisions, the undocumented workarounds — takes 2–3 months of living with the system. By the six-month mark, they should know it better than the old partner did, because they’ve reviewed everything with fresh eyes.

What if we’re unhappy with the new partner too? Are we stuck?

No. The relationship isn’t a marriage. If the new partner isn’t working, you can switch again. But be honest about whether the issue is them or your internal processes (see the self-assessment checklist above). Companies that switch partners every 12 months have a pattern, not a partner problem. Fix the internal issues, then find the right partner.

---

The Bottom Line

Staying with a Business Central partner who’s slow, uncommunicative, and coasting on your monthly retainer costs you more than the invoice. It costs you features you don’t know exist. It costs you processes that could be faster, simpler, and more automated. It costs you peace of mind during month-end close and release wave upgrades.

Switching isn’t painless — the first few weeks require attention, and if your old partner is uncooperative about source code, it costs money. But the alternative — years of quiet frustration, workarounds, and a system that never quite delivers — is more expensive.

If the warning signs in Section 1 sound familiar, and the self-assessment in Section 2 cleared your own house — it’s time.

Book a confidential conversation about switching →

No pressure, no commitment. We’ll answer the questions this article raised, walk through what a switch would look like in your specific situation, and help you figure out whether moving makes sense — even if it ends up being to someone else.

---

Vanguard 360 Solutions is a Microsoft Dynamics 365 Business Central partner and LS Retail Gold Partner. We’ve completed over 50 end-to-end implementations across Europe, the UK, UAE, and Saudi Arabia, and we support 70+ active customers across 13 countries. Switching partners is something we handle regularly — and we’re honest about what it takes.