Choosing the right Microsoft Dynamics partner is one of the most important decisions you will make in a GP to Business Central migration, and most organizations don't realize that until they're already mid-project.
TL;DR: Not all Microsoft Dynamics partners are equipped for a GP to Business Central migration. Before you start evaluating vendors, get clear on your GP version, data quality, internal bandwidth, and what success looks like. Then look for a partner with real GP-to-BC migration experience, industry references, and a support model that continues after go-live.
A quick note on scope: this post is written from inside the GP to BC migration world specifically, since that's where I spend my days. But most of these questions aren't really about GP or Business Central. They're about how to tell a good Microsoft partner from a mediocre one. If you're evaluating a partner for Power Platform, CRM, Azure, or anything else in the Microsoft ecosystem, the same instincts apply.
Most of what follows applies whether you're looking at a reseller, a managed service provider, or a trusted partner. If those terms are still blurring together for you, I break that down separately here: Choosing a Technology Partner: VAR, MSP, or Trusted Advisor.
Choosing the right Microsoft Dynamics partner is one of the most important decisions you will make in a GP to Business Central migration, and most organizations don't realize that until they're already mid-project.
If some of this sounds less like evaluating a new partner and more like describing the one you already have, that's worth naming too: Is It Time to Look for a New Technology Partner?
If you're a GP user starting to look at Business Central, you've probably already noticed something: there are a lot of Microsoft partners out there. They all have websites that look similar, they all say they specialize in BC, and they all sound confident on the phone.
So how do you figure out who actually knows what they're doing?
That's what this post is about. Not a checklist you hand to a partner during a demo, but a set of questions you should be asking yourself, before you get into conversations, so you walk in knowing what matters to you and what a good answer actually sounds like.
Before you can evaluate a Microsoft Dynamics partner, you need to get honest about a few things on your end.
A GP-to-BC migration isn't like buying software. You're not just picking a product, you're entering a relationship with an implementation team that is going to be embedded in your business for months. The partner you choose will influence your go-live timeline, your data quality, and how your team feels about the transition.
That's not meant to scare you. It's meant to put appropriate weight on this decision.
The 10 questions below are designed to help you get clear before you shop.
This one sounds basic, but you'd be surprised how many organizations get into partner conversations without a clear answer. Partners will ask. And if you don't know, it signals that you're earlier in the process than you may realize.
Before you start evaluating partners, know your GP version, how many years of historical data you're carrying, what your customizations look like, and roughly how clean (or messy) your data is. This shapes everything about how a partner will scope the project and what they'll charge.
Why it matters: A partner who doesn't ask these questions early is a partner who's going to surprise you with scope changes later.
This is a bigger issue than most people realize, and it's worth addressing head-on.
There are partners in the Microsoft ecosystem who have built their entire practice around GP, and that's all they do. They know GP well. They may have supported your system for years. But if they don't have an active Business Central practice, they cannot take you where you need to go. Some of these partners are quietly hoping their clients hold on to GP as long as possible, because BC isn't part of their business model.
GP expertise is genuinely valuable. But for a migration to Business Central, you need a partner who is actively doing BC work, not one who is just getting started to keep up with the market.
What to ask yourself: Is the partner I'm talking to invested in BC as a core part of their practice, or does it feel like something they added recently?
This is related to the question above, but worth separating out. There's a real difference between a partner who has been implementing Business Central for several years and one who started ramping up in the last 12 to 18 months because they saw where the market was heading.
GP-to-BC migrations have specific wrinkles: chart of accounts mapping, the data migration tools Microsoft built specifically for GP customers, and the places where GP logic just doesn't translate one-
to-one into BC. A partner with years of real BC migration experience has already run into those problems and knows how to handle them. One who is still building their practice is figuring it out as they go.
You want someone who has been through this specific transition before, not someone learning it alongside you.
What to look for: Ask how many GP-to-BC migrations they've completed, when they started doing BC work, and whether the consultants who will actually be on your project have hands-on migration experience, not just certifications.
Here's a gentle reality check: you don't have to have all the answers. But you do need to have some of them.
Do you know which business processes are most broken right now? Do you have a sense of your must-have integrations? Do you know whether you'll need multi-entity or multi-currency support? These aren't trick questions, they're the things a good partner is going to walk you through anyway. But if you've thought about them in advance, you'll have much better conversations.
What to do: Before you meet with any partner, do an internal assessment. Even a rough one. What's working in GP? What isn't? What do you want to be different in 12 months?
A migration doesn't just happen on the partner's side. It requires real time and attention from your finance team, your IT lead, and your department heads who own specific processes.
Be honest about what you have. If your finance team is stretched thin, or if you're about to go through a big operational change, that matters. The best partners will ask about this. The ones who don't are either going to set unrealistic timelines or set you up for a painful go-live.
The question to sit with: Do we have the internal bandwidth to do this migration right, at the timeline we're considering?
Not the vendor's definition of success. Yours.
Is it going live on a specific date? Is it getting off on-premise infrastructure? Is it reducing the time your team spends on month-end close? Is it finally having reporting that doesn't require an Excel gymnastics session every quarter?
Write it down. Being able to articulate this clearly, to yourself first and then to a partner, is one of the clearest signals that you're ready to have a productive conversation.
Why it matters: Partners who ask about this are partners who care about outcomes. Partners who don't ask are partners who care about implementation hours.
Microsoft has thousands of Dynamics partners. There's a meaningful difference between a generalist who can implement BC and a partner who has done it specifically in your industry, whether that's manufacturing, distribution, nonprofit, professional services, or something else. BC has industry-specific functionality, and a partner who knows your industry will configure it differently than one who doesn't.
What to look for: Ask about their customer base. Ask for references from organizations similar to yours in size and industry, not just logos on a slide deck.
This is one of the most underweighted questions in any Dynamics partner evaluation, and one of the most important.
Go-live is not the finish line. The period right after is often when you need the most support, when your team is learning the system, when something doesn't work quite the way you expected. What does ongoing support look like? Is it a helpdesk ticket system? Do you have a named contact? What's the average response time?
Some partners are excellent at implementation and thin on support. Others have a well-defined post-go-live service model. Know what you need before you ask.
What to clarify: Who specifically will support us after go-live, and what does that relationship actually look like?
I'm not going to pretend price doesn't matter, of course it does. But in my experience, the organizations that make partner decisions primarily on price tend to have more painful migrations, and often end up spending more in the end, not less.
A lower quote sometimes reflects a leaner team, less experienced consultants, or a scope that's missing things you'll need. It can also reflect genuine efficiency. The point is that price alone doesn't tell you which one you're looking at.
What to evaluate alongside price: Team experience, references, support model, and whether the scope actually matches what you told them you needed.
This is my favorite question, and the one I'd weigh most heavily.
A good partner, a real trusted advisor, should be honest with you when you're not ready. They should tell you if your timeline is unrealistic, if your data needs cleanup before migration starts, or if your organization isn't in the right place for a big change right now. They should be asking questions, not just pitching.
If a partner is pushing you to commit quickly, skipping hard questions about your current state, or telling you everything is simple when you suspect it isn't, pay attention to that.
The gut check: Does this partner feel like they're on our side, or like they're trying to close a deal?
Once you've answered these questions for yourself, here's a quick reference for what a strong Dynamics partner relationship actually looks like compared to a weaker one.
|
Area |
What a Strong Partner Does |
What Should Give You Pause |
|
Discovery |
Asks detailed questions about your current GP setup, data, and processes |
Jumps to demo or proposal without understanding your situation |
|
GP-to-BC experience |
Has completed multiple GP-to-BC migrations and can speak to specifics |
References only general BC implementations or is new to BC |
|
BC tenure |
Has been actively implementing BC for several years |
Built their BC practice recently to keep up with market demand |
|
Industry fit |
Has references from organizations similar to yours in size and industry |
References are vague or hard to follow up on |
|
Scoping |
Proactively flags complexity and risks, pushes back on unrealistic timelines |
Agrees with everything, scope feels too clean |
|
Post-Go-Live |
Has a clearly defined support model with named contacts |
Support is described vaguely as "we'll be there for you" |
|
Pricing |
Scope aligns with what you told them you needed |
Quote is significantly lower than others with no clear explanation |
|
Honesty |
Tells you what's hard and what might not work |
Everything sounds easy and fast |
I want to be straight with you on this one, because I've seen these patterns cause real problems.
The "we do everything" pitch. A partner who claims to be equally great at GP migrations, custom development, Power Platform, and a dozen other things may not be deeply excellent at any of them. Specialization matters in ERP implementation.
A GP-only shop trying to figure out BC. If a partner's core practice is still built around GP and they're just beginning to learn BC, that's a mismatch for where you're headed. GP expertise is real and valuable, but it doesn't automatically transfer to a BC implementation. You want a partner who has been doing BC migrations for years, not months.
Consultants who've never worked in GP. On the flip side, if the team doing your migration has only ever worked in BC and doesn't know GP, they won't understand why your chart of accounts is set up the way it is, or why your reporting structure made sense even if it doesn't map directly to BC. That's not a small gap either.
Vague answers about who will actually do the work. You might meet senior consultants during the sales process and then get handed off to a junior team after you sign. Ask directly: who specifically will be assigned to this project?
Pressure to decide quickly. A "this pricing is only available through end of month" conversation is a sales tactic, not a sign of a good partner. A partner who's confident in their work isn't in a hurry to get your signature.
One of the most common questions we hear, and one of the hardest to answer without knowing your situation. Here's a general framework based on what we see in practice:
|
Implementation Complexity |
Typical GP-to-BC Timeline |
|
No complexity: straightforward environment, clean data, no customizations |
12 weeks |
|
Moderate complexity: some customizations, relatively clean data |
6 to 9 months |
|
High complexity: significant customizations, multiple integrations, or messier data |
9 to 12+ months |
These are ranges, not guarantees. Data quality, internal bandwidth, the number of integrations you're carrying, and how well-scoped the project is on day one all affect the timeline significantly. Be cautious of any partner who gives you a firm number before they've done a thorough discovery of your environment.
Before you have your first partner conversation, it helps to know where you stand internally. The more of these you can check off, the more productive those conversations are going to be.
☐ We know our current GP version
☐ We have a sense of our data quality and what cleanup may be needed
☐ We know which customizations and integrations we're running
☐ We know how many years of historical data we want to bring over
☐ We've identified which processes are most broken or manual today
☐ We know our must-have integrations for day one
☐ We've talked internally about multi-entity or multi-currency needs
☐ We've written down what success looks like for us specifically
☐ We've identified who internally will own this project
☐ We've had an honest conversation about bandwidth and timing
☐ We're not in the middle of another major operational change
The organizations I've seen have the smoothest migrations aren't always the ones with the biggest budgets or the most technical sophistication. They're the ones who did their homework first, who got clear on what they needed, asked the right questions, and chose a partner they trusted.
You don't have to have everything figured out before you start having conversations. But knowing what you're evaluating for puts you in a much stronger position than walking in the cold.
And if a partner makes you feel like you need to rush, or that your questions are too detailed, or that you should just trust the process, that's information too.
If you're still getting oriented on what a GP-to-BC migration actually involves, these resources may be helpful before you start the partner search:
How do I evaluate a Microsoft Dynamics partner for a GP to BC migration?
Start by assessing your own readiness before you shop. Know your GP version, your data quality, your internal bandwidth, and what success looks like for your organization. Then look for a partner with specific GP-to-BC migration experience, several years of active BC implementation work, and references from organizations similar to yours. The comparison table above covers the key areas to evaluate.
How many GP-to-BC migrations should a partner have completed before I trust them?
There's no magic number, but you want to see more than a handful. Ask for specifics. A partner who can walk you through past migrations, what went smoothly, what didn't, and what they learned, is a partner who has actually done the work. One who has done two or three migrations is still building that knowledge base. Ask specifically about projects comparable to yours in size and complexity.
What's the average cost of a GP to Business Central migration?
Costs vary widely based on company size, number of users, customization depth, data migration complexity, and the support model you choose. Smaller, straightforward implementations may run in the range of $33,000 to $75,000. More complex projects with multiple entities, significant customizations, or large data sets can run considerably higher. A reputable partner will scope your project before quoting, not the other way around.
Is GP going away?
Microsoft has announced that product support and updates for Dynamics GP will end on December 31, 2029. GP isn't going away tomorrow, but the trajectory is clear, and December 2029 arrives faster than most people expect.
What is a Microsoft Solutions Partner designation?
As of 2022, Microsoft replaced the Gold and Silver partner tiers with a "Solutions Partner" designation model. Partners must demonstrate customer success metrics, active certifications, and performance scores across specific solution areas to earn and maintain the designation. It's a more meaningful bar than the old model, but it still doesn't tell you everything. Ask specifically about Business Central and GP-to-BC migration experience, not just the badge on their website.
Can we talk to Enavate even if we're not sure we're ready to migrate yet?
Absolutely. A big part of what we do is helping GP users figure out where they stand and what makes sense for them, without any pressure to commit to anything. If you want a straightforward conversation about your situation, that's exactly where we start.