There are roughly 4,000 Microsoft Business Central partners worldwide. Their websites all look the same: same blue color scheme, same « certified » badges, same case studies featuring smiling executives in front of dashboards. From the outside, it is almost impossible to tell who will actually deliver and who will burn 18 months of your time.
We have been on both sides of this table. As partners, we have won and lost RFPs. As consultants, we have rescued projects from partners who looked impeccable on paper. Here are the twelve questions we recommend you ask before signing anything. They are designed to surface the difference between a real Business Central practice and a sales team with a few certifications.
Why the wrong partner costs more than the wrong product
Microsoft Dynamics 365 Business Central is a mature, well-engineered ERP. When it fails, it fails because of the people implementing it, not because of the product. The Gartner statistic that 50 to 70 percent of ERP projects « fail » is misleading: in most cases, the product works fine, but the partner picked the wrong scope, lied about the team, or could not handle the political dynamics of the client.
This means your partner choice is the single highest-leverage decision in your entire ERP journey. A great partner with an average product beats an average partner with a great product, every time. Spend the time to choose well.
The 12 questions to ask any Business Central partner
Question 1 — How many Business Central projects have you delivered in the last 24 months? Pay attention to the answer. « Hundreds » is a red flag (no partner can really track that). « Eight » is a green flag (specific, honest, easy to verify). Anything below 5 in 24 months means they probably don’t have an active practice.
Question 2 — Can I speak to two reference clients with a profile similar to mine? A partner who hesitates here is a partner who doesn’t have good references. A partner who proudly gives you three names with phone numbers is telling you they have nothing to hide.
Question 3 — Who exactly will work on my project, and what is their seniority? Ask for names, LinkedIn profiles, and years of BC experience. Be specific. The senior consultant who sold you the project is rarely the one who will actually deliver it. You want to meet the project manager, the lead developer, and the functional consultant before signing.
Question 4 — What is your approach to handling existing customizations? A good partner will tell you: « We audit them first, then we make a keep/redesign/drop decision for each one ». A bad partner will say: « We migrate everything to keep things simple ». The second answer means they don’t understand the BC update model.
Question 5 — How do you handle data cleansing? If they don’t bring up data cleansing in the first conversation, run. Data work is 20 to 30 percent of any serious project and the partner who skips it is the partner who will blow up your go-live.
Question 6 — What does a typical project plan look like for a company my size? They should walk you through phases (discovery, design, build, data, test, train, go-live, stabilization), give you indicative timing, and explain how they handle each phase. If they can’t describe their methodology, they don’t have one.
Question 7 — How do you price: fixed fee, time and materials, or hybrid? There is no wrong answer, but each model has trade-offs. Fixed fee gives you cost certainty but tempts the partner to cut corners. Time and materials gives flexibility but no cap. Hybrid (fixed per phase, T&M for change requests) is usually the cleanest. Ask which they prefer and why.
Question 8 — What is included in the price, and what triggers a change request? Get this in writing. « Out of scope » is the most expensive phrase in ERP. A good partner has a clear, written definition of scope and a defined process for handling scope changes. A bad partner has a verbal understanding and a habit of sending invoices.
Question 9 — How do you handle BC’s twice-yearly updates after go-live? Microsoft releases two BC updates per year. A real partner has a regression testing process, a defined update cadence, and a service line item for this. A weak partner will say « we’ll figure it out », which means you’ll figure it out alone.
Question 10 — What happens if we discover scope changes mid-project? This question reveals their default posture. The right answer is: « We stop, document the change, evaluate impact on cost and timeline, and ask for your decision before continuing ». The wrong answer is: « We absorb it and sort it out at the end » (read: we’ll send you a big invoice at the end).
Question 11 — Will you push back when our requests don’t make sense? This is the most important question. A great partner says « yes, that’s part of the job » and gives you an example. A bad partner says « we always do what the client wants ». You don’t want a partner who says yes to everything. You want a partner who tells you when you’re about to make a mistake.
Question 12 — Show me an example of an AL extension you’ve written. The twelfth question is the one most prospects forget. Ask to see real code from a real customer project (with permission). Code quality is the difference between an extension that survives five BC updates and one that breaks at the next release. A partner who can’t show you their code is a partner whose code you don’t want.
Red flags that should end the conversation
Beyond the twelve questions, there are five red flags that should end your conversation regardless of how good the rest looks.
First red flag: the partner can’t tell you who will work on your project. If they say « we’ll assign the right team » without names, you’re hiring an anonymous slot, not a team.
Second red flag: the partner pushes for a sales decision before you’ve done discovery. A good partner wants you to do discovery first because they want a successful project. A bad partner wants the contract before you discover problems.
Third red flag: the partner can’t show you a real customer they delivered, in your industry, in the last two years. Generic case studies don’t count.
Fourth red flag: the partner positions themselves as « the only » solution. Healthy partners tell you when their competitors are a better fit. They know the market is big enough.
Fifth red flag: the partner doesn’t want to do a paid discovery. A free « demo » is a sales meeting. A paid discovery is a real engagement where you learn what they actually do.
Green flags worth a premium
Conversely, here are three green flags that justify paying more for a partner.
First green flag: a written, public point of view on how they do things. A partner with a real methodology has a blog, white papers, conference talks. They’re not hiding their thinking.
Second green flag: a senior consultant who tells you when you’re wrong. The first time a partner pushes back on one of your requests during the sales process, take it as a positive signal. They care about outcomes more than about closing.
Third green flag: a clean approach to AL extensions. A partner who proudly shows you a small, well-documented extension they wrote two years ago that still works on the latest BC version is a partner who understands long-term engineering.
How Asio Services approaches this
We believe partner selection is too important to leave to a sales process. That is why we offer two things most BC partners don’t.
First, a paid discovery phase. Before we quote a project, we spend a few thousand euros worth of time understanding your business, your data, and your team. The output is a written diagnostic, a recommended scope, and a real number. If you decide not to work with us, you keep the diagnostic. It belongs to you.
Second, a code sample on request. We will send you, under NDA, a sample of AL code we have written for a real customer (anonymized). We want you to see how we work before you commit to working with us.
If this is the kind of partner you are looking for, we would love to talk.
→ Book a free discovery call with Asio Services. We will go through your situation, answer your toughest questions, and give you a clear-eyed view of what working together would look like.
