Confirm experience with the product you need

Dynamics 365 is a family of applications. Experience with one does not automatically establish experience implementing another. Ask the partner to identify the exact product and deployment model proposed, along with the work its team has delivered using that product.

For Business Central, describe your accounting and operating needs. For a CRM project, explain the sales, customer service or other processes involved. Where more than one application is proposed, ask who understands the connections between them.

Request examples with comparable complexity. Relevant experience might involve multiple companies, warehouse operations, project billing or migration from your existing system. A business in another industry may still offer a useful comparison if the processes are similar.

Ask the partner to explain where the proposed product fits and where another application or custom work may be needed. A useful answer identifies limitations as well as capabilities and gives your team a way to assess the trade-offs.

Look for evidence behind the proposal

Compare the material each partner can provide during evaluation. Focus on evidence that helps you understand the people, approach and responsibilities behind the estimate.

Ask about current Microsoft credentials and the experience of the people assigned to your work. Credentials are one part of the review; they do not explain whether the proposed team has delivered your specific processes. Confirm claims rather than assuming a logo answers that question.

Meet the people who will deliver the work

Ask to meet the proposed project manager and the consultants responsible for your main processes. Find out whether the people involved in discovery will remain involved during configuration, testing and launch.

Clarify the use of subcontractors or other providers. Ask what they will do, how their work is reviewed and who remains accountable for the overall result. Include access to your information in that discussion.

Confirm availability, working hours and time zones. A team can work effectively across locations, but the plan should allow for workshops, decisions and urgent questions during hours your staff can attend. State any on-site work expected and how travel will be charged.

Ask what happens if a key consultant becomes unavailable. Look for a practical handover process, documented decisions and someone who can take over. Knowing how the team manages a change in personnel is more useful than assuming the same people will always be available.

Review how the partner learns about your business

Discovery should examine how work moves through the business. Ask how the partner will involve finance, operations, IT and daily users, and what it will document before making major configuration decisions.

Bring representative transactions, reports and exceptions. For example, explain how an order is approved, what happens during a partial delivery and how a price discrepancy is resolved. The partner should ask enough questions to understand the complete process.

Microsoft’s Success by Design framework provides guidance across the implementation lifecycle. Ask a partner that refers to a framework to explain how it affects your project: the reviews it will hold, decisions it will record and evidence it will use.

Find out what discovery produces and whether it is a separately priced stage. Ask when the estimate will be revised and how unresolved requirements will be presented. A named methodology is useful when it leads to clear project activities.

Request a demonstration based on your workflows

Give shortlisted partners the same small set of scenarios. Ask them to show the standard approach, identify configuration work and explain any additional applications needed. Include an exception so you can see how the process handles imperfect conditions.

Have the employees responsible for the process review the demonstration. Record unanswered questions and request written clarification. Compare how each partner explains the work, rather than judging only the appearance of the demonstration.

Check the division of responsibility

Ask who will prepare data, agree on report calculations, configure permissions, test processes and train users. Each important activity needs a responsible person or team and a clear expected result.

Microsoft’s project approach guidance discusses customer responsibilities alongside partner work. Your employees usually need to make business decisions and confirm results, even when the partner handles configuration and technical delivery.

Review the time requested from your team. A proposal based on prompt decisions and prepared records may be unrealistic if the same employees are handling a busy close or seasonal workload. Ask how the plan changes when those assumptions do not hold.

Also clarify responsibility across providers. If an e-commerce company, payroll supplier or internal IT team must contribute, include their tasks and availability. The implementation partner should explain how these dependencies will be coordinated.

Ask how migration results will be verified

A migration discussion should cover more than the tool used to import records. Ask how the partner will assess source data, agree on what moves and identify information that stays in an archive.

Confirm who cleans up duplicates, resolves missing details and approves changes to codes. Ask how trial transfers will be reviewed and how your team will reconcile balances and unfinished transactions before the final move.

For integrations, request the proposed method, information flows and failure-handling process. Ask who investigates a missing order or a rejected record, how the problem is logged and how a retry avoids duplicates.

Where Business Central is being considered, Joesoftware’s Dynamics GP migration guidance provides context for deciding what to migrate and archive. Use your own records and operating needs to establish the actual scope with the proposed team.

Review testing, training and launch criteria

Ask how the partner plans testing and how employees will participate. The plan should cover relevant transactions, reports, permissions and integrations, with expected results that your team can check.

Discuss the time allowed for corrections and repeat testing. Ask how the team records issues, assigns responsibility and decides whether an unresolved problem prevents launch. A launch date needs supporting readiness evidence.

Training should reflect roles and the configured processes. Confirm whether employees can practise realistic tasks, who answers follow-up questions and what materials remain available. Find out how changes made after training will be explained.

Before signing, ask who approves the final transition and which checks must be complete. Review the proposed plan for the data transfer, operational interruption and communication with affected employees. Clarify how a decision to postpone would be managed.

Compare commercial terms on the same basis

Request a breakdown of subscriptions, implementation services, additional applications and support. For Canadian budgeting, confirm the quotation currency, taxes, billing terms and any charges priced in another currency.

Compare inclusions and exclusions before comparing totals. A lower estimate may assign more migration, testing or training work to your employees. Ask what those responsibilities involve and whether your team has the capacity to fulfil them.

Check how changes are approved. A fixed fee should define the work it covers; an hourly proposal should explain rates, estimated effort and reporting. In either case, identify who can approve additional spending.

Ask which records and materials you receive, including configuration notes, integration documentation and any custom-development handover agreed in the contract. Clarify access to your data and what assistance would be available if another provider later takes over.

Understand what support looks like after launch

Ask where employees report problems, which hours are covered and how urgent issues are escalated. Distinguish a target response time from a commitment to resolve a problem; the two describe different things.

Find out whether ongoing support comes from the implementation team or a separate group. Either arrangement needs a clear handover. The support team should understand the configured processes, integrations and unresolved items it is receiving.

Microsoft’s transition and handover guidance discusses transferring knowledge into ongoing operations. Ask how the partner will put that into practice and who will maintain the documentation.

Confirm how future updates, new staff and process changes will be handled. Identify what is included in recurring support and what requires a separate estimate. These responsibilities affect the relationship long after the first successful transactions.

Use references to test the partner’s claims

Request references the partner has permission to share, ideally involving similar processes or complexity. Ask what the partner delivered, which responsibilities the customer held and what happened when an assumption changed.

Discuss communication, data preparation, training and support rather than asking only whether the project finished on time. A useful reference explains the circumstances behind the result and where the customer needed to contribute.

Before deciding, record the evidence, open questions and proposed next step for each partner. Give greater attention to requirements that are essential to your business. A strong overall impression should not obscure an unresolved gap in a critical workflow.