Your Business Central partner is supposed to make your ERP investment easier to manage.

That sounds obvious, but it is worth asking what “easier to manage” actually means.

It should mean more than having somewhere to send a support ticket. It should mean that when something goes wrong, somebody takes ownership. When Microsoft changes the platform, you know what matters to your business. When a process is inefficient, there is someone who can challenge the way it works rather than simply reproduce it in code. And when you spend money on development, consulting or an extension, you understand why the investment is necessary and what it is expected to achieve.

The problem is that ERP relationships can become reactive without anyone making a deliberate decision for them to become that way.

A support issue is raised. The customer waits. Someone follows up. A workaround is provided. A few months later, the same issue appears in a slightly different form. A small requirement becomes a development project. Another extension is installed. The next upgrade creates more testing work. The partner completes the upgrade, but nobody steps back to ask whether the underlying solution has become more complicated than it needs to be.

Meanwhile, the invoices continue.

At that point, the question should not simply be whether your Business Central partner is expensive.

The more useful question is:

Are we getting enough value from the total cost of this relationship?

That is a much harder question, but it is also a much better one.

The cost of an ERP relationship is not limited to what the partner charges. It can include the time your employees spend chasing support, correcting data, maintaining workarounds, explaining the same problem repeatedly, testing unnecessary customisations, managing third-party applications and waiting for decisions. It can also include the cost of opportunities that were never pursued because nobody was looking at the ERP environment proactively.

This matters even more in 2026. Business Central is no longer a platform that customers can sensibly treat as “implemented and finished.” Microsoft continues to evolve the application through major release waves, while the platform increasingly includes Copilot and agent-based capabilities. Microsoft’s current upgrade guidance for versions 26 through 28 also highlights the effect that extensions, deprecated functionality and application changes can have on upgrade preparation.

That changes the role a customer may reasonably expect from its partner.

Not every organisation needs a strategic consultant sitting in every ERP meeting. A company with a stable environment and a clearly defined reactive support contract may be perfectly happy with a conventional support model.

But if you are paying for a broader partnership and still feel that you have to discover, diagnose and prioritise everything yourself, it is worth examining why.

What should a Business Central partner actually be responsible for?

Microsoft describes the Business Central partner as the frontline for technical support. Customers have a partner who assists with technical support, while the partner is expected to triage requests, investigate issues and either resolve them or escalate them to Microsoft.

That establishes the support responsibility.

It does not, by itself, define what a mature commercial relationship should look like.

There is a significant difference between a partner fulfilling the minimum support function and a partner that understands the customer's business well enough to advise on the environment.

Imagine two customers with the same Business Central issue. Both raise a support ticket. Partner A resolves it and closes the ticket. Partner B resolves it, but also notices that the same issue has appeared six times in the last year. Partner B asks why. Perhaps the problem is not a software defect at all. Perhaps users are following a process that was designed years ago and no longer fits the way the business operates. Perhaps a customisation is creating the problem. Perhaps a standard Business Central capability can now replace the workaround.

The technical resolution may be identical.

The value of the relationship is not.

That distinction is useful when reviewing a partner because it prevents the discussion from becoming a simplistic argument about response times. Good support matters, but the larger question is whether the partner is helping the organisation become less dependent on recurring support in the first place.

The nine signs below are therefore not a checklist for deciding whether a partner is “bad.” They are indicators that the relationship may not be delivering the level of value, visibility or technical stewardship that your organisation expects.

Top 9 Signs Your Business Central Partner Is Costing You More

1. Your team has to chase support

Every ERP environment has difficult support cases.

A problem may involve an integration, a third-party application, a data issue, a custom extension or a Microsoft service. Some incidents simply take time to diagnose. A slow resolution on one complicated ticket is not enough to conclude that a partner is failing.

The warning sign is the pattern.

If your finance manager has to send a second email to find out whether anyone is working on an issue, then another message to ask for an update, and then another message because the promised response never arrived, the organisation is spending time managing the support process instead of the ERP problem.

That internal effort is easy to overlook because it does not appear on the partner invoice.

Suppose a finance team spends two hours each week chasing open ERP issues. Over a year, that is more than 100 hours of internal time before anyone has actually solved another problem. The exact number will differ by organisation, but the principle is important: support quality has an internal cost as well as a supplier cost.

There is another distinction worth making.

Good support is not necessarily about resolving everything immediately. It is about creating confidence that an issue is controlled.

If the issue is complex, the customer should know who owns it, what has been investigated, what happens next and whether escalation is required. Microsoft itself describes the partner as the frontline support contact responsible for triaging and investigating customer requests and escalating them when necessary.

That gives customers a useful benchmark for the basic responsibility, but service expectations still need to be defined contractually.

The better question to ask your partner is therefore not simply, “Why did this ticket take so long?”

Ask:

“Can we identify the recurring support issues in our environment and determine which ones should be eliminated rather than repeatedly resolved?”

That changes the conversation from ticket management to service improvement.

A mature support review should reveal patterns: recurring incidents, ageing tickets, repeated workarounds, areas with unusually high support demand and issues that keep returning after supposedly permanent fixes.

If the same problem appears every quarter and the only response is another ticket, there may be a process or solution-design problem hiding underneath the support problem.

2. Small problems keep turning into billable projects

There is nothing wrong with paying your Business Central partner for professional services.

Development costs money. Consulting costs money. Integrations cost money. Major upgrades cost money. A partner cannot provide unlimited specialist work for free.

The concern begins when you cannot explain why the same category of problem keeps generating new expenditure.

Consider a relatively common scenario.

A business has a finance process that is awkward in Business Central. The first year, the partner provides a workaround. The following year, the customer asks for a small development. Later, an additional report is commissioned because the original change did not provide enough visibility. A third-party application is then introduced to handle another part of the process.

Individually, each decision may have been reasonable.

Five years later, however, the customer may be maintaining a collection of solutions around the original problem without anyone having revisited the original business requirement.

That is where ERP expenditure becomes difficult to evaluate.

The question is not:

“Was this invoice legitimate?”

The question is:

“Why does this business problem still require this much expenditure?”

A good partner should be able to help separate unavoidable specialist work from recurring expenditure caused by weak process design, technical debt or a solution that has simply aged.

This is particularly important in Business Central because standard functionality changes over time. A requirement that genuinely needed custom development several years ago may be easier to address today using standard functionality, configuration or a supported extension.

That does not mean every old customisation should be removed. It means the original business justification should be revisited periodically.

A useful annual review is to take the previous 12 months of Business Central expenditure and ask what each significant item achieved.

Support should tell you where the environment is consuming operational effort.

Development should tell you which business problem was addressed.

Third-party applications should have a current reason for existing.

Training expenditure should be examined alongside user adoption.

Upgrade costs should be compared with the level of technical complexity in the environment.

And optimisation expenditure should be visible enough that management can see whether the partner is actually improving the system or simply keeping it running.

The goal is not to make every category smaller.

The goal is to make the relationship more understandable.

3. Your Business Central environment is becoming more complicated every year

Technical debt rarely arrives as a major decision.

It usually arrives as a series of reasonable decisions.

A customer needs a new approval process, so an extension is installed.

A reporting requirement cannot be met easily, so a custom report is developed.

A warehouse system needs to exchange data with Business Central, so an integration is created.

A department finds a gap in the standard process, so another customisation is introduced.

Three years later, the environment works, but nobody can explain all of it with confidence.

That is a technical-debt problem.

It is important not to confuse this with an argument against customisation. Business Central is designed around extensions, and Microsoft continues to rely heavily on an extension-based architecture. Custom development and third-party applications can be exactly the right answer when the business has a genuine requirement that standard functionality cannot reasonably address.

The problem is unmanaged accumulation.

Microsoft's current upgrade guidance explicitly warns that a large number of installed extensions can negatively affect performance and upgrade operations. Microsoft recommends installing only the extensions required for business processes and regularly reviewing those that are no longer needed.

That has a practical implication for customers.

You should not be satisfied with knowing that an extension is installed. You should know why it is installed.

Imagine a distribution company with 25 extensions. Perhaps 10 are clearly required for core processes, five support integrations, four are reporting-related, three were installed for historical requirements and three have unclear ownership.

The number 25 is not automatically a problem.

The fact that nobody knows what seven of them are doing is.

This is where an experienced partner should be able to provide an environment map rather than simply an app list.

For each significant extension or custom component, you should be able to understand its business purpose, owner, publisher, dependencies, support arrangement and importance to daily operations.

You should also be able to answer a more uncomfortable question:

“If we implemented Business Central again today, would we build all of this the same way?”

The answer will often be no.

That is not a criticism of the original implementation. Business requirements change. Microsoft changes the product. Third-party solutions mature. Organisations acquire other businesses and change processes.

The mistake is assuming that yesterday's solution design should remain untouched forever.

4. Your upgrades start with a deadline instead of a plan

Business Central's release model makes upgrade readiness an ongoing management issue.

Microsoft's current documentation covers preparation for versions 26, 27 and 28 and specifically identifies deprecated or redesigned functionality, extension changes, dependencies and upgrade considerations. Microsoft also documents a dedicated upgrade path for Business Central 2026 release wave 1, version 28.

This matters because an upgrade is not simply a button that changes the version number.

The impact depends heavily on what has been built around the standard application.

A relatively clean environment with limited customisation may have a straightforward upgrade path.

An environment containing multiple extensions, custom development, integrations and historical modifications requires considerably more analysis and testing.

This is where the partner's role becomes visible.

A reactive partner starts the conversation when the upgrade date becomes urgent.

A proactive partner starts earlier by looking at the environment and identifying what might need attention.

For example, Microsoft notes that changes to application functionality can require custom extension code to be changed, while large numbers of extensions can increase upgrade duration and risk.

The customer does not need a 40-page technical report every release.

What the customer needs is a clear answer to a much simpler set of questions:

What has changed?

What affects us?

What needs testing?

What might break?

What should we retire?

What should users know?

What should we budget for?

That is the difference between an upgrade project and an upgrade discipline.

The strongest partners also use upgrades as opportunities to simplify.

If an extension is no longer needed, review it.

If a customisation duplicates standard functionality, investigate whether it can be retired.

If an integration has become unreliable, decide whether it still belongs in the architecture.

If users are working around a process, ask whether the upgrade is a good opportunity to redesign it.

The objective is not to turn every upgrade into a transformation programme.

It is to avoid spending money reproducing yesterday's complexity in tomorrow's environment.

5. You cannot explain what your Business Central spend is achieving

This is where the conversation moves from IT into management.

A CFO does not necessarily need to know how many hours a developer spent modifying an AL extension.

The CFO does need to understand why the organisation spent the money.

Imagine being asked:

“What did we spend on Business Central last year, and what did we get for it?”

If the answer is simply the total value of supplier invoices, there is a visibility problem.

You should be able to distinguish between the cost of keeping the system operational and the cost of changing or improving it.

Those are not the same thing.

Support keeps the business running.

Development changes the system.

Consulting helps make decisions.

Training should improve adoption.

Optimisation should improve the way the business uses the system.

Upgrades protect the platform's ability to move forward.

Third-party applications should solve specific requirements that justify their ongoing cost.

Once those categories are separated, the commercial discussion becomes more useful.

You may discover that the partner is not actually expensive. You may discover that the environment simply requires too much support because it is unnecessarily complex.

Or you may discover the opposite: the partner's rates are reasonable, but the organisation is paying repeatedly for work that should have been solved more permanently.

This is why hourly rates are a poor standalone measure.

A partner charging £100 an hour is not necessarily cheaper than one charging £150. If the first requires twice as many hours to reach the same outcome, the apparent saving disappears.

For the same reason, a higher-cost consultant may be economically better if they identify the root cause, remove recurring workarounds and reduce the amount of future intervention required.

The useful management question is therefore:

“What is the total cost of operating and changing our Business Central environment, and what business value are we getting in return?”

You may not be able to calculate that value precisely.

You should still be able to discuss it intelligently.

6. Your partner is very good at fixing problems but rarely talks about improving the system

This is one of the most important distinctions in the entire article.

A partner can provide excellent support and still not be the right strategic partner for your organisation.

Consider two relationships.

In the first, the partner responds quickly, resolves incidents and delivers requested development. The customer is generally satisfied.

In the second, the partner does all of those things but also periodically asks why certain issues keep occurring, where users are struggling, which customisations have become unnecessary and what changes in Business Central could improve the customer's processes.

Neither partner is necessarily doing a bad job.

They are providing different levels of value.

The problem occurs when the customer believes it is buying the second model while actually receiving the first.

A simple way to test this is to ask your partner:

“If you were responsible for improving our Business Central environment over the next 12 months, what would you change?”

Do not ask for a generic list of Business Central features.

Ask for three recommendations based on your actual environment.

A credible answer should contain specifics.

Perhaps the partner has noticed that warehouse users are entering the same information in multiple places. Perhaps finance is relying on a custom report that can now be replaced. Perhaps an integration is creating unnecessary support tickets. Perhaps users are licensed for functionality they are not adopting. Perhaps an old extension is increasing upgrade complexity without delivering enough value.

The quality of the answer tells you something about how closely the partner understands your environment.

This is also where organisations should be realistic about contracts.

If you have deliberately purchased a reactive support arrangement, you should not expect unlimited proactive consulting to appear for free.

But if you are paying for account management, managed services, continuous improvement or strategic advisory, proactive recommendations should be part of the conversation.

The issue is not whether every partner must behave like a consultant.

It is whether the service you are paying for matches the service you think you are receiving.

7. You are learning about relevant Business Central AI capabilities before your partner tells you about them

This is one of the more interesting partner-review questions in 2026 because the technology is moving faster than many organisations' ERP governance.

Business Central's AI story is no longer limited to simple productivity assistance. Microsoft's 2026 release documentation includes agent-based capabilities, while Microsoft continues to expand Copilot and other AI functionality across Business Central.

That does not mean every customer should be implementing AI.

It means the partner should be able to have an informed conversation about it.

Suppose your finance team processes a high volume of supplier invoices.

A weak AI conversation sounds like:

“Microsoft has a Payables Agent. You should look at it.”

A stronger conversation starts with the business process.

How are invoices received today?

How much data is entered manually?

How often do invoices match purchase orders and receipts?

How many invoices require exceptions?

Who reviews those exceptions?

How are approvals handled?

Where does the process slow down?

Only after understanding that process does it make sense to evaluate whether a Microsoft capability could help.

The same principle applies to expense processing, sales assistance, planning, customer service or other AI scenarios.

The partner's job is not to become an AI salesperson.

It is to help the customer distinguish between available, relevant, ready, and worth implementing.

That distinction matters because Microsoft capabilities have their own prerequisites, availability conditions and deployment considerations. Customers should not assume that a feature described in Microsoft's release documentation is automatically available in every Business Central environment. Microsoft's current documentation also distinguishes online scenarios from other deployment models.

There is a broader point here.

A good partner should sometimes tell you not to implement a new AI capability.

If the expected volume is too low, the process is already efficient, the prerequisites are not met, the business case is weak, or the required controls are disproportionate to the benefit, “not yet” may be the correct recommendation.

That is advisory value.

The test is therefore not:

“Did my partner tell me about every new AI feature?”

It is:

“Does my partner understand the new capabilities well enough to explain which ones matter to my business, which ones do not, and why?”

8. Critical Business Central knowledge exists only inside people's heads

This is one of the least visible forms of ERP risk.

It often becomes obvious only after someone leaves.

A consultant knows why a particular extension was developed.

A finance manager knows why a certain posting setup exists.

An IT employee understands how an integration is monitored.

A warehouse manager knows the workaround users follow when a particular process fails.

Nobody thinks much about it because the people are still there.

Then one of them leaves.

Suddenly, a system that has been operating for years becomes surprisingly difficult to explain.

The problem is not simply missing documentation.

It is organisational dependency.

A mature Business Central environment should have enough documentation for another qualified professional to understand its important moving parts. That does not mean documenting every click a user can make. It means documenting the decisions and dependencies that would otherwise be lost.

For example, if a critical integration fails at month-end, somebody should know what it connects, who owns it, how it is monitored and what the recovery process is.

If an extension is business-critical, somebody should know why it exists and who supports it.

If a customisation changes a standard process, there should be enough information to understand the business reason behind it.

And if a particular configuration is essential to financial operations, it should not depend entirely on the memory of one consultant.

A useful test is uncomfortable but revealing:

“If our current partner disappeared tomorrow, how long would it take another qualified Business Central professional to understand our environment?”

If the answer is “months,” that does not automatically mean the partner has done something wrong.

But it does mean the customer has a dependency risk.

There is another reason to care about this when changing partners.

Microsoft's current guidance places significant responsibility on partners and extension publishers to keep apps and per-tenant extensions aligned with the Business Central release rhythm.

If the customer cannot explain what custom code and extensions exist in the first place, it becomes harder to manage that dependency.

Documentation is therefore not bureaucracy.

It is part of making the ERP environment transferable, supportable and governable.

9. Your partner reports completed work instead of explaining what changed for the business

This is where many ERP relationships stop short of becoming genuinely strategic.

“The upgrade is complete.”

“The extension has been installed.”

“The development has been delivered.”

“The issue has been resolved.”

All of those statements may be true.

None of them tells management whether the business is better off.

Take an invoice-automation project.

The technical team might report that invoice processing has been automated.

Management should still want to know what that means.

Did manual data entry fall?

Did processing time fall?

How many invoices still require human intervention?

Are exceptions handled more quickly?

Did the number of posting errors change?

Did the finance team actually save time?

The same principle applies to reporting.

Saying that a new dashboard has been delivered is not an outcome.

If management used to spend three hours assembling information every month and can now get the same information in ten minutes, that is an outcome.

The difference may sound subtle, but it changes how ERP investments are managed.

A partner does not need to promise a precise ROI percentage for every project. Some benefits are qualitative, and some are difficult to isolate from wider business changes.

But the partner should be prepared to define what success looks like before the work starts.

That might be a reduction in processing time, fewer support incidents, improved data quality, faster reporting, lower manual effort, stronger controls or better adoption.

The metric should follow the business problem.

If the problem is slow reporting, measure reporting effort.

If the problem is recurring data entry, measure manual processing.

If the problem is upgrade risk, measure the technical debt and dependencies being removed.

If the project is an AI initiative, measure the process impact and the level of human intervention that remains.

The point is not to turn ERP into a spreadsheet of artificial ROI calculations.

The point is to stop confusing delivery with value.

The hidden cost is usually bigger than the invoice

These nine signs are connected.

A support problem that is not properly investigated can create a workaround.

The workaround can create inconsistency.

The inconsistency can lead to customisation.

The customisation adds complexity.

The complexity makes the next upgrade harder.

The upgrade requires more testing and consulting.

The additional cost creates frustration.

Users then work around the system again.

The cycle continues.

This is why a CFO looking only at partner invoices can miss a significant part of the ERP cost.

Imagine a company spending £80,000 a year on Business Central-related partner services.

That number alone tells you very little.

Perhaps the partner is providing excellent support, proactive optimisation and well-planned upgrades.

Or perhaps the organisation is spending £80,000 because the environment is difficult to maintain, users need repeated workarounds and every improvement requires custom development.

The invoice is the same.

The underlying economics are completely different.

A more useful review considers the partner's fees alongside internal employee time, manual processing, recurring errors, delays, third-party applications, technical risk and missed opportunities.

You do not need to pretend this can be calculated with accounting precision.

The purpose is to ask a better management question:

“What does our ERP environment really cost us to operate, maintain and change?”

Once that question is asked, the partner relationship becomes much easier to evaluate.

Before changing partners, give the relationship one serious test

A poor experience does not automatically mean you should change partners.

ERP relationships are complicated. A new partner needs time to understand the environment, and changing partners can introduce its own risk.

Before making a decision, document the problems.

Do not write:

“Support is bad.”

Write:

“Eight of our last 20 support incidents exceeded the agreed response expectation, and four required repeated follow-up from our finance team.”

Do not write:

“The partner keeps charging us.”

Write:

“We spent £X on development relating to the same process over the last 18 months, and we do not have an agreed target for when the underlying issue will be considered resolved.”

Specific evidence creates a much better conversation.

Then give the partner a reasonable opportunity to respond.

A useful 60- or 90-day improvement discussion might cover support ownership, recurring incidents, documentation, upgrade readiness and a small number of specific optimisation opportunities.

For example:

“We have reviewed our Business Central relationship and identified recurring issues around support responsiveness, cost visibility and proactive improvement. We would like to agree on measurable changes over the next 90 days and review the results together.”

The response tells you something.

A partner that listens, investigates and produces a credible plan may be worth retaining.

A partner that dismisses the evidence, avoids ownership or immediately turns the discussion into another sales pitch may be telling you something equally important.

When changing your Business Central partner becomes a rational decision

There is a difference between frustration and structural failure.

Changing partners because one project went badly is usually not enough.

Changing partners after years of recurring support problems, weak communication, unclear technical ownership and little proactive improvement is a different decision.

A partner change becomes more rational when the problems are persistent, material and have not improved after being clearly raised.

That might include a combination of unresolved support issues, poor communication, unpredictable expenditure, unmanaged customisation, weak documentation, inadequate upgrade preparation, limited Business Central expertise or an inability to engage with your changing business requirements.

The key word is persistent.

If you have raised the same problem several times and the relationship does not change, you have more evidence than if you simply had one bad experience.

Before making the move, however, understand what you are actually transferring.

If you change partners, technical due diligence matters

Changing a Business Central partner is not simply changing the name on a supplier invoice.

The incoming partner inherits an environment that may contain years of decisions.

They need to understand the deployment model, Business Central version, extensions, custom development, integrations, critical business processes, open issues, licensing arrangements and documentation.

This is particularly important because Business Central's modern architecture is heavily extension-based. Microsoft’s upgrade documentation explains that application functionality is delivered through extensions and that extension dependencies and changes can affect upgrade preparation.

A responsible incoming partner should therefore begin with discovery.

They should be able to tell you what is standard, what is custom, what comes from a third party, what is business-critical, what is obsolete and what represents immediate technical risk.

They should not walk in on day one and announce that everything needs to be rebuilt.

That is a red flag in itself.

A good transition often starts with an environment assessment, documentation review and risk register.

Only after the new partner understands the architecture should major changes be proposed.

This is also where licensing and contractual arrangements matter. The mechanics of changing partners can vary depending on the customer's Microsoft licensing, commercial agreements, deployment model and existing support arrangements.

In other words, switching partners is a business decision, but it is also a technical transition.

Treating it as either one or the other creates unnecessary risk.

What should a Business Central partnership look like in 2026?

The old ERP model was relatively straightforward:

Implement → support → upgrade → repeat

That model still works for some organisations.

But Business Central's evolution is pushing other customers toward a different relationship:

Operate → optimise → automate → evaluate new capabilities → manage change → measure outcomes

The important word is not AI.

It is change.

Business Central is changing. Microsoft is changing the application. Extensions change. Business processes change. Organisations acquire companies, enter new markets, change operating models and adopt new technology.

This is where an ongoing Business Central relationship matters. A partner such as Dynamics Square UK needs to stay engaged as the customer's business evolves—not simply maintain the environment that was originally implemented. That means understanding how the business is using Business Central today, where the current solution is creating friction, and where changes to the platform or the business may require a different approach.

That might lead to conversations such as:

“Your warehouse process is generating too many manual exceptions. Is the issue with the system, or has the process itself changed?”

“Your extension portfolio has grown significantly. Are there applications that now overlap with standard Business Central functionality?”

“This Microsoft release changes an area that affects one of your customisations. What should we test before the update?”

“You are continuing to pay for a third-party application. Does it still provide enough value to justify the cost?”

“Your finance team is spending significant time on this process. Is there now a sensible opportunity to automate part of it?”

“The system is stable, but critical knowledge appears to sit with only two people. What happens if either of them leaves?”

These are different from simply telling a customer that a new feature is available.

They connect the technology to an actual business problem.

That distinction is important because a good Business Central partner should not be measured by how many Microsoft features it can demonstrate. It should be measured by how well it can determine which changes are relevant, which are unnecessary, and which are worth investing in.

The best partner is not the one that tells you about every Microsoft feature.

It is the one that can tell you which features you should ignore.

Five questions worth asking your Business Central partner now

If you want to test the quality of the relationship without starting a confrontation, ask five questions.

1. What are the biggest risks in our current Business Central environment?

Do not accept a generic answer.

Ask the partner to identify the risks based on your actual extensions, integrations, customisation and business processes.

2. If you were responsible for our ERP roadmap for the next 12 months, what would you change?

This tests whether the partner understands the environment beyond support tickets.

3. Which parts of our solution are unnecessarily complex?

A partner that has been maintaining the environment should be able to identify areas where complexity has accumulated.

4. Which new Business Central capabilities are genuinely relevant to our business?

The useful answer should distinguish between features that are available, relevant, immature, unsuitable or not worth the investment.

5. What should we stop doing?

This is perhaps the most revealing question.

ERP optimisation is not always about adding functionality.

Sometimes the best improvement is removing an old report, retiring an extension, eliminating a workaround or stopping a manual process that exists only because “that is how we have always done it.”

A partner that can identify what should stop may understand your environment better than one that always has something new to sell.

The simplest test: would you choose the same partner today?

There is one final question that cuts through much of the noise.

Imagine you are selecting a Business Central partner today.

You know what you know now.

You know how support works.

You know what the relationship costs.

You know how much customisation exists.

You know how upgrades have been handled.

You know how well the partner understands your business.

You know how proactive they are.

You know whether they help you plan for Microsoft changes.

You know whether they can discuss automation and AI intelligently.

Now ask:

“Knowing all of that, would we choose this partner again?”

If the answer is an immediate yes, that is useful confirmation.

If the answer is “maybe,” ask what would need to change.

If the answer is “no,” do not treat that as an instruction to terminate the relationship tomorrow.

Treat it as a reason to investigate.

Sometimes the problem is the partner.

Sometimes the problem is the service model.

Sometimes expectations were never defined properly.

Sometimes the organisation itself has allowed technical debt and undocumented processes to accumulate.

And sometimes the right answer is to reset the relationship rather than replace it.

The point is to make the decision based on evidence rather than frustration.

Final takeaway

A Business Central partner is not necessarily costing you too much because its hourly rates are high.

The relationship may be expensive because it requires too much internal effort, too much recurring development, too much technical maintenance and too little proactive improvement.

That is why the most useful partner review goes beyond invoices.

Look at how support is handled.

Look at how recurring problems are solved.

Look at how customisation is governed.

Look at how prepared the environment is for Microsoft updates.

Look at whether the partner understands the capabilities Business Central is gaining.

Look at whether important ERP knowledge is documented.

And, most importantly, look at whether technical work is connected to business outcomes.

The nine signs are not proof that you have the wrong partner.

They are prompts for a more serious conversation.

A good Business Central partner should not simply help you keep yesterday's ERP running.

They should help you understand what you have, reduce unnecessary complexity, prepare for what is changing, and make sensible decisions about what comes next.

The best Business Central partner is not necessarily the cheapest partner.

It is the partner that helps you get more business value from the platform without creating unnecessary technical or commercial complexity.

Is your Business Central partner still delivering the value you need?

Dynamics Square can help you assess your current Business Central support relationship, technical environment, optimisation opportunities and roadmap through a Business Central Partner Review.

The purpose is not automatically to recommend changing partners.

It is to give you an independent view of where the environment stands, where avoidable cost or risk may exist, and what practical options you have for the next stage.

Book a free 15-minute Business Central Partner Review.

Frequently Asked Questions

What are the biggest signs of a poor Business Central partner?

The strongest indicators are usually patterns rather than isolated incidents. These can include recurring support problems, poor communication, unclear ownership, repeated development around the same business problem, unmanaged customisation, weak upgrade preparation and little proactive discussion about improving the environment.

How do I know whether my Business Central partner is overcharging me?

Do not compare hourly rates alone. Review the total cost of support, development, consulting, third-party applications and internal employee time. Then ask what business problems those costs are solving and whether the same issues continue to generate expenditure.

A partner with a higher hourly rate may still deliver better value if it resolves problems faster, reduces recurring work and avoids unnecessary development.

Should a Business Central partner proactively recommend improvements?

That depends partly on the service you have purchased. A reactive support contract may not include ongoing optimisation.

If, however, you expect a managed-service or strategic relationship, proactive recommendations should be part of the discussion. The partner should understand your environment well enough to identify opportunities to improve processes, reduce technical debt, prepare for upgrades and evaluate relevant new capabilities.

Should my Business Central partner be helping with AI?

The partner should at least be able to assess relevant Business Central AI capabilities and explain whether they are appropriate for your organisation.

That does not mean recommending every new Microsoft capability. In some cases, the correct advice will be to wait because the business case is weak, prerequisites are not met, the feature is not sufficiently mature, or the process itself needs to be improved first.

Is Business Central AI available to every customer?

Not necessarily. Availability depends on the individual capability, deployment model and other Microsoft requirements. Microsoft's current release documentation should be checked for the latest availability, prerequisites and status of specific Copilot and agent capabilities. Customers should not assume that a capability announced by Microsoft is automatically enabled or suitable for every environment.

How often should I review my Business Central partner?

An annual structured review is a sensible minimum for most organisations.

You should also consider a review after a major upgrade, a significant business change, repeated support issues, a major increase in ERP expenditure, an acquisition, a change in technology strategy or a decision to expand automation and AI.

Can I change my Business Central partner?

A partner change may be possible, but the process depends on your Microsoft licensing, contractual arrangements, deployment model and existing solution.

Before switching, make sure the incoming partner understands the environment, extensions, customisations, integrations, open issues and business processes. A structured transition is much safer than allowing a new partner to start changing the system without understanding what is already there.

Is changing Business Central partners risky?

It can be if the transition is poorly managed.

The biggest risk is not usually the act of changing the commercial relationship. It is losing knowledge about the existing solution or allowing a new partner to make technical changes before it understands the architecture.

A proper transition should begin with technical and functional discovery, documentation, risk assessment and a clear handover plan.