Blog
How to choose a Business Central implementation partner
Search Console shows us what people were looking for when they landed on this site, and two of the most frequent searches are versions of “compare Business Central implementation partners in Lithuania” and “help me find a reliable partner”. Those deserve a better answer than a services page, so here it is: the checklist we would use if we were the ones choosing.
Full disclosure first. ArvyDev is one of the companies you would be comparing, so read everything below with that in mind. We have tried to keep every point verifiable, so the checklist works whichever partner ends up across the table.
How much can one person cover?
Nearly every partner has a dedicated Business Central team these days, so “do you specialise in BC” no longer separates anyone. The question that does: how much of your scope can a single person carry? In large teams people specialise narrowly. One knows finance, another the warehouse, a third the API layer. Every requirement that crosses two areas then needs two people, a handover and a meeting, and the work that spans both takes double the time. Worse is when a narrow specialist is pushed outside their patch: a person who knows one functional corner, delivering in another, produces amateur results at best.
So ask how many people your scope actually requires. The fewer people who each cover more of Business Central, the fewer handovers you pay for, and the fewer seams between areas that nobody owns.
Certifications you can actually verify
Microsoft’s partner ecosystem has two layers worth checking, and both are public. At company level, look for the Solutions Partner for Business Applications designation. At individual level, the exams that matter for BC are MB-800 (functional consultant) and MB-820 (developer). Then ask the only question that makes the paper meaningful: are the certified people the ones assigned to your project? A firm’s certificate count tells you little if the holders are on other engagements and yours is staffed with whoever was free.
Ask them: standard or custom?
Put a real requirement on the table and ask how they would solve it. The answer reveals the partner’s economics. A partner who reaches for custom code first earns more billable hours now and hands you a heavier system to carry through every future update. The answer you want to hear starts with configuration and standard features, and reaches for AL code only where your business truly differs; we wrote up why in extensions vs customising the base app. Everything custom is a red flag dressed as flexibility.
Meet the people, not the sales deck
The team in the pitch and the team in the project are not always the same team. Before signing, ask to meet the consultant and the developer who will actually do the work, and ask them, not the salesperson, how they would run your migration. Ten minutes of that conversation tells you more than any slide about methodology.
Quality comes from the people doing the work, not from the company’s past projects or the awards on its website. A long corporate track record does not mean a senior consultant will be assigned to you; smaller projects are routinely staffed with the least experienced people on the bench, because the seniors are reserved for the accounts that matter to the structure. Ask about staff turnover too. When the team changes year to year, each new person starts your project as if for the first time, and the hours they spend catching up appear on your invoices. A partner who keeps the same people on your project is buying you continuity: higher quality at a lower cost, because nothing has to be relearned.
Who does the quote actually pay for?
Large partners carry large structures, and their quotes reflect it. Alongside the consultant and the developer you will often find a project manager, an engagement manager, an account manager and an architect who appears in the rate card but never in the sprint. Some coordination is real work on a multi-country rollout. On an SMB project, scope has a way of expanding to feed the structure rather than the project: hours appear because the roles exist, not because the work demands them.
The test is simple. Go through the quote line by line and ask what each role produces that you could point to after go-live. Analysis, configuration, code, migrated data and trained users all pass that test; “oversight” billed at a senior rate usually does not. We scope in that order ourselves, the deliverables first and only the coordination they demand, which is easier when the people scoping the project are the people building it.
When a big partner is the right call
In fairness, a caveat. If your project is large, needs thousands of hours and has to land fast, a big partner can dedicate resources at a scale a small one cannot. That is a real advantage, and pretending otherwise would be marketing.
Two checks protect you either way. First, make sure the thousands of hours are buying delivery rather than feeding the administration: take at least one concrete task from the offer, ask other partners for a high-level estimate of the same task, and compare. Second, if the scope is large but the deadline is not pressing, ask whether the work can be split into phases. Delivered in stages, the same result is often within a smaller partner’s reach, at a better price.
Read the quote like a project plan
Two quotes for “a Business Central implementation” can differ by half, and the missing half is usually scope, not efficiency. Check what the number includes: a data-migration dry run, user training beyond a demo, integrations listed by name, and support for the first weeks after go-live. What drives the total is covered in what an implementation really costs; a quote you cannot map to those drivers is not a cheaper project, it is an unpriced one.
How to save
Beyond reading the quote well, a few purchasing habits reliably lower the total.
- Price the convenience. A big partner can sell everything as one package: licences, localization, products, services. That is comfortable, and the comfort is billed. Almost every piece of the package can be bought separately, and the points below are those pieces.
- Buy licences on price. Business Central licences are identical whoever resells them. Any partner can supply them, so even in a resale, choose the price: a higher margin on the same licence buys you nothing.
- Buy the right licences. Not everyone needs a full licence either. Users who only approve, look things up or enter timesheets fit a Team Member licence at a fraction of the cost, and Premium is only worth paying for if you use manufacturing or service management; our licensing guide walks through the tiers.
- Partner products stand alone. Nearly every partner product can be bought without that partner’s services attached. The Lithuanian localization apps in particular are distributed by everyone in the market, so even when you buy one indirectly, choose the price.
- Beware products without an alternative. A specialised product nobody else replicates ties you to its vendor, and when its pricing climbs you will feel the squeeze. Before adopting one, search for alternatives and know your way out.
- Benchmark standalone tasks. If the scope is large but parts of it stand alone (a specific report, an integration with system X), ask another partner to estimate exactly that piece. Standalone functionality can be built by anyone, so you should never overpay for it inside a bundle.
- Check AppSource before commissioning code. For common needs such as EDI, bank feeds or document capture, a ready AppSource app on subscription is usually cheaper than bespoke development, and its maintenance is the vendor’s problem rather than yours.
- Keep the exit open. Keep administrator access, your extensions’ source code and the documentation in your own hands. A partner who knows you can realistically switch prices accordingly, and you never have to say it out loud.
What happens after go-live
The go-live weekend is the midpoint of the relationship, not the end. Ask what the partner’s response times are and whether support is a contract or a favour. A partner who cannot answer plainly is planning to disappear.
Ask how support is billed, too. The standard model in this market is a monthly fee that runs whether you needed anything that month or not, often packaged as a retainer with included hours that expire unused. We do not charge one: support at ArvyDev is billed for the work actually done, and a month in which nothing needed doing costs you nothing. Whichever model you end up with, make sure it was a choice. A retainer signed by default is the scope inflation from the previous section, sold as a subscription.
Eight questions for the first meeting
- How many people will our scope need, and how much of it can each of them cover end to end?
- Who exactly will work on our project, and what have they built before?
- Which of your people hold MB-800 or MB-820 today?
- Here is one of our requirements: standard feature or custom code, and why?
- Which roles in the quote produce deliverables we can point to, and what do the others add?
- What does the quote include for data migration, training and post-go-live support, and is support a monthly fee or billed per work done?
- How long have the people assigned to us been with you, and how often do your project teams change?
- Can we speak to two customers of our size?
None of these need our involvement to be useful. Whoever you are comparing, the partner who answers all eight without flinching is the one to shortlist.
Already comparing candidates? Tell us your story and put us through the checklist; we are happy to sit the exam.