You’re about to spend $500,000 to $2 million and commit 9–18 months to this partnership. The implementation partner you choose will define whether your D365 project becomes a transformation success story or the next rescue case study.
After rescuing dozens of troubled D365 implementations, we’ve seen the same partner selection mistakes repeated across industries, company sizes, and geographies. The warning signs are remarkably consistent — and almost always visible during the sales process, if you know what to look for.
Here are the 10 red flags that should make you pause, ask harder questions, or walk away entirely.
Red Flag #1: They Promise a Fixed Price Before Seeing Your Data
What It Looks Like
The sales rep quotes you a number within 48 hours of your first conversation. They haven’t reviewed your legacy systems, haven’t asked about data volumes, and haven’t seen a requirements document because you haven’t written one yet. But they’re confident: “$650K, all-in, 12 months.”
Why It’s a Red Flag
Legitimate D365 scoping requires discovery. Partners need to understand your data landscape, process complexity, integration requirements, and organizational readiness before they can responsibly estimate costs. A partner who quotes upfront is doing one of two things: padding the estimate significantly to cover unknowns (you’ll overpay), or planning to hit you with change orders once the project starts (you’ll still overpay, just later).
Professional partners invest in discovery before pricing. They want to understand what they’re committing to. If a partner is willing to quote blind, they either don’t care about accuracy or don’t understand the risks.
What to Do Instead
Insist on a standalone Discovery Statement of Work before committing to full implementation pricing.
Here’s how this works: instead of asking partners to quote the entire project upfront, engage them for a fixed-scope, fixed-price discovery phase first. A professional discovery engagement typically runs 2–4 weeks and costs $15,000–$30,000. It includes:
- Stakeholder interviews across all business functions
- Current-state process documentation and gap analysis
- Technical environment assessment (integrations, data volumes, infrastructure)
- High-level requirements gathering and prioritization
- Data quality assessment and migration complexity evaluation
The deliverable is a comprehensive scoping document that includes a detailed implementation roadmap with phases and dependencies, an itemized cost estimate with all assumptions explicitly documented, a resource plan specifying named consultants and their time allocations, a risk assessment with identified mitigation strategies, and a realistic timeline with phase-gate milestones and decision points.
Why this approach works: It shifts the risk. You’re paying $15,000–$30,000 for discovery — a small, controlled investment — and in return you get an honest, evidence-based view of what the full project will actually cost and entail. If the discovery phase uncovers deal-breaking complexity, reveals that your requirements don’t align with D365’s capabilities, or demonstrates that the partner isn’t the right fit, you’ve spent $20,000 to avoid a $500,000 mistake.
The litmus test: Professional partners will welcome a standalone discovery SOW. It demonstrates your seriousness as a client, gives them a paid opportunity to prove their capability before you commit to the full engagement, and ensures they’re scoping based on facts rather than assumptions. Partners who resist paid discovery — claiming it’s “unnecessary” or that they “include it for free” in their implementation quote — are often the same partners who’ll hit you with change orders six months into the project when reality diverges from their optimistic estimate.
If a partner won’t commit to a standalone discovery engagement with clear deliverables and a fixed price, that’s not a negotiation issue. It’s a selection issue. Find a different partner.
Red Flag #2: Their “Senior Consultants” Are Unavailable for Discovery
What It Looks Like
The sales team is polished and impressive. The deck looks great. The demo is flawless. But when you ask to meet the actual consultants who will be on your project, you get excuses: “They’re on client sites right now,” or “We’ll assign the team after contract signature.”
Why It’s a Red Flag
You’re not buying a product — you’re buying access to people. If the senior consultants who supposedly have 10+ years of D365 experience aren’t available to participate in scoping, they won’t be available during delivery either.
This pattern typically means one of two things: the senior people exist but are overallocated across too many projects (you’ll get 20% of their time when you need 80%), or the “senior consultants” are actually mid-level resources being marketed as senior (you’ll get people learning on your dime).
What to Do Instead
Require that the proposed project team participate in at least two discovery sessions before you sign. Meet them. Ask about their D365 experience, their familiarity with your industry, and their availability. Get written commitments on who will be assigned and for how many hours per week.
If the partner can’t or won’t commit named resources before contract signature, assume you’re getting the B-team.
Red Flag #3: They Don’t Ask About Your Current Processes
What It Looks Like
The conversation is entirely focused on D365 capabilities: modules, features, integrations, deployment options. The partner talks about what D365 can do. They don’t ask what you currently do, how you do it, or why you do it that way.
Why It’s a Red Flag
D365 implementations are not lift-and-shift migrations. The platform is designed around specific process flows and data models. If a partner isn’t deeply curious about your current state — your workflows, pain points, workarounds, exceptions — they’re planning to configure D365 to replicate your existing processes, broken or not.
This leads to one of two outcomes: either you end up with a system that doesn’t leverage D365’s capabilities (expensive status quo), or the partner hits a wall mid-project when they realize your processes don’t map to D365’s design (expensive rework).
What to Do Instead
A professional partner should spend more time in discovery asking about your business than talking about D365. They should want to understand your order-to-cash cycle, your month-end close process, your inventory management approach. They should challenge assumptions: “Why do you do it that way? What would happen if you didn’t?”
If the partner’s pitch is 90% product demo and 10% business questions, that ratio will carry into implementation — and you’ll pay for it.
Red Flag #4: The Demo Feels Too Perfect
What It Looks Like
The demo is slick. Every click works. Every screen loads instantly. The data looks suspiciously clean. When you ask a question about a specific scenario (“What if a customer returns a partial order after invoicing?”), the answer is smooth but generic: “D365 handles that natively.”
Why It’s a Red Flag
Polished demos are rehearsed environments, not your environment. If a partner can’t — or won’t — show you how D365 would handle your specific edge cases, data quirks, and process exceptions in real-time, they either don’t understand the platform deeply enough or they’re hiding complexity.
Real implementations are messy. Data doesn’t load perfectly. Integrations fail. Workflows have exceptions. A demo that never breaks isn’t showing you D365 — it’s showing you theater.
What to Do Instead
Ask the partner to configure something live during the demo. Bring a real scenario from your business — ideally one that’s complicated — and ask them to show you how they’d configure it in D365. Watch them work. See how they handle roadblocks. Competent consultants can navigate the platform in real-time. Salespeople reading scripts cannot.
Red Flag #5: They Can’t Demonstrate Relevant Industry Expertise
What It Looks Like
When you ask about experience in your industry, the response is vague: “We’ve done lots of manufacturing projects.” When you press for specifics — discrete vs. process manufacturing, make-to-stock vs. make-to-order — the answers stay generic.
More importantly: When you ask to meet the actual consultants who will work on your project and discuss their industry background, you get deflected. The firm might list impressive clients on their website, but the people sitting across from you can’t speak credibly about your specific business challenges.
Why It’s a Red Flag
D365 is highly configurable, which means industry-specific knowledge matters immensely. Discrete manufacturing and process manufacturing use the same D365 Supply Chain Management module, but the configuration approaches are fundamentally different. Professional services firms and distribution companies both run D365 Finance, but their chart of accounts structures, revenue recognition models, and reporting requirements have almost nothing in common.
What matters isn’t just the firm’s client list — it’s whether the consultants assigned to your project understand your industry. A boutique partner with a thin corporate portfolio might be an excellent choice if their senior consultants have deep vertical expertise gained across multiple firms or previous employers. Conversely, a large partner with an impressive client roster might staff your project with junior consultants who’ve never configured D365 for your vertical.
Generic ERP experience doesn’t translate. Consultants who have never worked in your industry will spend the first three months of your project learning your business on your budget.
What to Do Instead
Ask two separate questions:
- Firm-level: “Can you provide references from companies in our industry vertical?” (Ideally 2–3 references with similar scale and operational complexity)
- Consultant-level: “Can we meet the specific consultants who will be assigned to our project and review their individual industry backgrounds?”
Then dig into the consultant backgrounds with specific questions:
- How many projects in our vertical have you personally delivered?
- What role did you play? (Lead architect vs. junior developer matters)
- Can you walk me through a specific challenge you solved in a similar environment?
- What industry-specific pitfalls should we watch for in our implementation?
Here’s the key insight: A small firm with limited vertical references but senior consultants who have 10+ years in your industry is often a better choice than a large firm with an impressive client list but junior consultants learning on your dime.
Red flags within the red flag: The firm can’t or won’t commit specific consultants before contract signing; the proposed consultants are vague about their industry background when pressed; or references are provided but the consultants who delivered those projects are no longer with the firm.
Green flags: The proposed consultants can speak fluently about industry-specific D365 configuration patterns (even if the firm’s corporate portfolio is thin); consultants demonstrate they’ve encountered and solved problems specific to your vertical; or the firm is transparent: “We’re a smaller shop, but Sarah and Mike have each done 15+ discrete manufacturing implementations between them.”
If the consultants assigned to your project don’t have genuine industry depth — regardless of the firm’s marketing materials — move on.
Red Flag #6: The Contract Has Vague Deliverables
What It Looks Like
The statement of work lists phases (“Discovery, Design, Build, Test, Deploy”) but doesn’t define what gets delivered in each phase. Line items say things like “Implementation Services” or “Project Management Support.” When you ask what specific documents or outputs you’ll receive, the answer is “standard project artifacts.”
Why It’s a Red Flag
“Implementation services” is not a deliverable. It’s a placeholder. Professional statements of work specify outputs: functional design documents, technical design specifications, data migration scripts, test plans with defined entry and exit criteria, training materials, go-live runbooks.
Vague contracts create two problems: you don’t know what you’re paying for, and the partner has no accountability for delivering it. When the project goes sideways — and with vague contracts, it will — there’s no objective standard for whether the partner fulfilled their obligations.
What to Do Instead
Insist on a deliverables-based contract. Every phase should list specific outputs with clear acceptance criteria. Example: “Phase 2 deliverable: Functional Design Document covering all in-scope modules, including process flows, configuration decisions, and business sign-off, due Week 8.”
If the partner resists specificity, assume they’re planning to define “success” retroactively.
Red Flag #7: They Downplay the Importance of Change Management
What It Looks Like
When you bring up training and user adoption, the response is dismissive: “We’ll do training in the last two weeks before go-live,” or “D365 is intuitive — users will figure it out.” Change management is treated as a “nice to have,” not a project workstream.
Why It’s a Red Flag
User adoption is not optional. It’s not a soft skill. It’s the difference between a $1.5M D365 system that transforms operations and a $1.5M D365 system that sits unused while everyone continues working in Excel.
Partners who treat change management as an afterthought either don’t understand organizational dynamics or don’t care about post-go-live success. Either way, you end up with a technically functional system that no one uses.
What to Do Instead
Change management should be a formal workstream in the project plan, with dedicated resources, a budget, and measurable outcomes. Look for partners who talk about super-user programs, role-based training plans, executive sponsorship strategies, and post-go-live adoption tracking.
If the partner’s answer to “How will you ensure user adoption?” is “We’ll train them,” find a partner who understands that training is the floor, not the ceiling.
Red Flag #8: They Recommend Heavy Customization Immediately
What It Looks Like
Early in the discovery process — sometimes in the first conversation — the partner starts talking about custom development: “We’ll build a custom module for that,” or “We’ll extend that entity with custom fields.” The default answer to every business requirement is code.
Why It’s a Red Flag
Out-of-the-box D365 handles 80% of most organizations’ use cases. Customization should be the last resort, not the first answer. Heavy customization creates four problems: it’s expensive to build, expensive to maintain, difficult to upgrade, and often unnecessary once the business process is properly understood.
Partners who jump to custom code first are either padding billable hours or lack deep platform knowledge. Experienced D365 consultants know how to configure the standard platform to meet complex requirements. Inexperienced consultants code around gaps in their own understanding.
What to Do Instead
Ask the partner to justify every customization recommendation. For each proposed custom development, ask: “Can this be achieved through standard configuration? What native D365 functionality would we lose by customizing? What’s the long-term maintenance cost?”
Professional partners treat customization as a measured trade-off, not a default response. If the partner’s instinct is “build custom,” not “configure standard,” keep looking.
Red Flag #9: They Don’t Have Skin in the Game on Outcomes
What It Looks Like
The contract is 100% time-and-materials with no performance incentives, deliverable milestones, or outcome-based terms. The partner gets paid whether the project succeeds or fails. When you ask about shared risk or success-based pricing structures, the response is dismissive: “That’s not how we structure engagements,” or “We bill by the hour — it’s industry standard.”
Why It’s a Red Flag
Partners who refuse any outcome alignment are optimizing for billable hours, not your success. When there’s no financial consequence for delays, scope creep, or poor delivery, the incentive structure is misaligned. You absorb 100% of the risk while the partner absorbs none.
Professional partners are willing to tie at least some portion of their compensation to results. This doesn’t mean the entire engagement needs to be fixed-price — but it does mean the partner should be willing to demonstrate confidence in their delivery through contract structure.
Common risk-sharing mechanisms include: milestone-based payments where you don’t pay for Phase 3 until Phase 2 deliverables are formally accepted; go-live success fees where the partner earns a bonus if the system goes live on time and on budget; holdback provisions where the final 10–15% is paid 30–60 days post-go-live once the system is proven stable; or fixed-price phases where specific workstreams (like data migration or integration development) are scoped and priced definitively rather than billed hourly.
What to Do Instead
Look for partners willing to structure at least partial risk-sharing in the contract. This doesn’t mean you should demand the entire project be fixed-price — D365 implementations have too many variables for that to be realistic in most cases. But a partner should be willing to commit to deliverable-based milestone payments (not just time tracking), a withheld final payment contingent on post-go-live system stability, or fixed-price treatment of well-defined work packages like specific integrations or reports.
Ask explicitly: “Are you willing to tie any portion of your fee to delivery milestones or go-live success?” Professional partners who are confident in their methodology will say yes. Partners who refuse entirely are telling you something about their track record.
The best partnerships have aligned incentives. If your success is their success — financially, not just rhetorically — the relationship starts on the right foundation.
Red Flag #10: They Don’t Discuss What Happens If the Project Fails
What It Looks Like
Every conversation is optimistic. Timelines are aggressive but confident. Risks are downplayed. When you ask “What’s your contingency plan if we miss the go-live date?” or “What happens if data migration fails?” the response is dismissive: “That won’t happen,” or “We’ve never had a project fail.”
Why It’s a Red Flag
Professional project managers plan for failure. They have rollback strategies, remediation plans, and clear accountability structures. They’ve thought through what happens if integrations don’t work, if user acceptance testing uncovers major gaps, if go-live has to be postponed.
Partners who refuse to discuss failure scenarios either have never experienced a troubled project (unlikely and concerning) or don’t want to acknowledge that their delivery model has gaps. Either way, when something does go wrong — and in complex ERP implementations, something always does — you’ll be dealing with a partner who didn’t plan for it.
What to Do Instead
Ask explicitly: “What’s your standard remediation process if the project gets off track? What does your rollback plan look like? How do you handle scope disputes?” Professional partners will have answers ready — documented processes, escalation paths, contractual terms that define accountability.
If the partner treats risk planning as negativity rather than professionalism, walk away.
Conclusion: Trust Is Earned, Not Sold
Choosing a D365 implementation partner is one of the highest-stakes decisions your organization will make in the next decade. The partner you select will define not just whether the technology works, but whether your people adopt it, whether your processes improve, and whether the investment delivers ROI or becomes a cautionary tale.
The best partners earn your trust before they earn your contract. They invest in understanding your business. They’re transparent about risks. They commit specific people with relevant experience. They treat your success as their accountability, not just their sales target.
If you’re evaluating D365 partners right now and want an independent assessment of your shortlist — someone who’s seen these partnerships play out and has no stake in who you choose — we offer a free 1-hour partner evaluation review.
No obligation. No sales pitch. Just honest feedback from people who understand what separates good partner selection from costly mistakes.
#Dynamics365 #D365 #ERPImplementation #ImplementationPartner #MicrosoftDynamics #PartnerSelection #ITLeadership #DigitalTransformation