Pre-Implementation
Checklist

Every item here is a sentence somebody has to write down. None of them require the platform, and all of them are quoted against.

• State the outcome in one sentence, and the measure that proves itNot "implement Dynamics 365". Something closer to "every quote is approved and out within one working day, and we can say what the pipeline is without exporting anything". If nobody can write that sentence, the requirements list will grow until the budget runs out.
• Name one executive sponsor and one decision maker per processA name each, not a department. The single most reliable predictor of a project sliding is a design question that sits unanswered because it belongs to a committee.
• Split requirements into must have and nice to have, with a date against eachA nice to have with no date is a must have in disguise. This list is also what protects a fixed price milestone from becoming an argument.
• Decide who owns the system in year two, and budget for it nowA named person or team, a support allowance, and a route for a change request. Plan from around twenty hours a month in the second year for a single Customer Engagement app. Unowned systems are the ones we get called about.
• Split the scope into configuration and engineering, using the eight walls aboveThis list is the thing you actually hand a consultant. It turns "we need a Dynamics 365 partner" into a scope with line items, and it is what lets you buy help for one wall rather than for the whole project.
• Fix the licence count and the licence mix before you scope the buildBase application licences, attach licences for a second application, Team Members, Power Apps per app, and Power Pages for anyone outside the organization. Design decisions that assume the wrong licence are found at renewal, which is the most expensive moment to find them.
• Write down what phase one delivers and what is explicitly deferredThe deferred list matters more than the delivered one. It is the document you point at when somebody asks in week six why the thing they never mentioned is not being built.

Wall six on this page is the most expensive one to unwind and the cheapest one to avoid. These seven items are how you avoid it.

• Stand up development, test, and production as separate environmentsThree environments from day one. Building in production because it is quicker is the decision that costs a year later, and it never feels like a decision at the time.
• Create your own publisher and prefix, and never build in the default solutionA named unmanaged solution in development, with your publisher on it. Components created in the default solution are the ones nobody can move, package, or cleanly remove afterwards.
• Agree that production and test only ever receive managed solutionsManaged into test and production, unmanaged only in development. This is what makes a component removable and a layer predictable, and it is a policy rather than a tool.
• Pick where the source lives and export into it from the first weekAzure DevOps, GitHub, or whatever your organization already uses. Unpacked solutions in a repository you own, not a zip file on a consultant laptop. Confirm in writing that this is yours at the end of the engagement.
• Set the data loss prevention policy before the makers arriveWhich connectors are business, which are not, and which are blocked. Retrofitting a policy onto flows people already depend on is a negotiation. Setting it first is an afternoon.
• Decide the Dataverse region at creation, against your data residency obligationCheck what the customer contract, the personal data law you are subject to, and any EU client of yours require before the database exists. Moving an environment between regions later is a support request and a plan, not a setting.
• Set the base currency and the base language at creation, and check them twiceBoth are fixed when the Dataverse database is created and cannot be changed afterwards. Phase six covers what the currency choice actually commits you to, and it is the single most common irreversible mistake we find on regional environments.

Security is the wall that needs no code, which is exactly why it gets left. Ownership and business unit changes move records later, not just permissions.

• List every process and put one owner name against itQuote approval, case escalation, discount authorisation, project contract sign off, credit hold. A person, not a role title and not a department. This list is the input to every item below it.
• Design business units around how records must be separated, not around the org chartThe org chart changes every year and the separation requirement rarely does. Business units built to mirror reporting lines are the ones that have to be rebuilt after the first reorganisation.
• Decide user ownership or team ownership per table, before there are recordsRecords owned by a person disappear from view when that person leaves. Records owned by a team survive it. Changing your mind later means moving every row.
• Turn each named owner into a security role, privilege by privilegeWrite out create, read, write, delete, append, append to, assign, and share for each table, at the depth you actually mean. If the answer to any of them is "everyone, organization wide", say why in the same document.
• Identify the columns that need field level securityCost, margin, discount ceiling, salary or day rate on a resource, and anything personal. It is a short list on most projects, and it is far cheaper to secure a column before people have grown used to seeing it.
• Decide how managers see their team, deliberatelyHierarchy security, a wider business unit, or a team. Three different answers with three different maintenance costs. Picking one by accident is how a sales manager ends up with organization wide read on everything.
• Agree who can export to Excel and who can run a bulk deleteThe two privileges most often left on by default and the two with the largest consequences. Export is your data leaving. Bulk delete is your data leaving permanently.
• Write down what happens when somebody leavesRecords reassigned, flows reassigned, and connections reassigned. Flows and connections owned by an individual account are the failure we meet most often, and it is always discovered the week after that person changes role.

Migration is the line item most often underestimated by an order of size. Almost all of that underestimate is cleaning, not loading.

• Count the rows per source table today, and write the numbers downAccounts, contacts, open and closed transactions, notes, and attachments. The counts decide the approach, the tooling, and the price. A partner who quotes a migration without asking for them has not scoped it.
• Decide the history cut off explicitlyTwo years, five years, open records only, or everything. Starting clean is a legitimate and much cheaper decision, and it should be a decision made in a meeting rather than a discovery made in the final week.
• Pick the one canonical customer list, and retire the othersOnly one system can win. Where the accounting system, the sales spreadsheet, and the old database disagree, name in advance which one is right and who arbitrates the exceptions.
• Choose a matching key you can defend, then deduplicate at sourceA tax identification or state registration number beats a company name every time. This matters more in the Caucasus than in most markets, because the same organization commonly exists once in Armenian or Georgian script and again in Latin transliteration, and name based matching silently treats them as two customers.
• Normalise phone numbers and addresses before the load, not afterInternational format for every number, including the country code, so that +374, +995, and +994 records behave the same as European ones in search, duplicate detection, and any telephony you add later.
• Decide what ownership and created on mean for migrated rowsIf history has to mean anything, original dates and original owners have to survive the move, and that is a different and larger piece of work from loading current data. Say which one you are buying.
• Create alternate keys on the source system identifierWith a key on the legacy identifier, a reload updates the row it already created instead of making a second one. Without it, the second attempt at a migration doubles your data, and there is always a second attempt.
• Rehearse into test at full volume, then reconcile and get a business sign offRow counts, financial totals, and a spot check by the people who know what the records should say. Migration rehearsal is the step that gets cut when a date slips, and it is the one that decides whether users trust the system in week one.

An integration that has never been given a retry policy looks fine for months and then quietly drops the record that mattered. This page is what prevents that.

• List each endpoint with system, direction, trigger, and volumeOne row per endpoint: what it talks to, which way data moves, what starts it, records per day, and records at peak. Count the rows before you accept any fixed price, because each one is an eight to twenty five engineer day line item when no maintained connector exists.
• Write the field level mapping for each directionIncluding what happens to a field the other side does not have, and which system wins when both have changed the same record. Undecided conflict resolution is decided by whichever job runs last, which is not a design.
• Name the authentication method and the account that owns itA service principal or an application user, never a named employee. Every integration authenticated as a person is a resignation away from an outage.
• Decide the idempotency key so a retry cannot duplicate a recordThe alternate key on the external identifier does most of this work. Without one, the first network timeout becomes two invoices for the same order, and it will be found by a customer rather than by you.
• Set a retry policy and configure run after behaviour on every flowBoth are defaults nobody changes and both decide what happens on the second attempt and on a partial failure. This is the difference between an integration that recovers and one that stops without telling anybody.
• Name the human who gets alerted on failure, and the channel that reaches themA failure notice in a mailbox nobody reads is not monitoring. Decide who is woken up, how, and what they are expected to do, and test it once before go live.
• Confirm channel and number availability for your countries before promising themEmail, telephony, and messaging channels are not uniformly available or uniformly provisioned across every country, and lead times on numbers are real. Verify for Armenia, Georgia, or wherever your users sit before a channel appears on a project plan.

This is the phase a generic checklist does not have. Regional projects almost always quote in one currency, report in another, and invoice in a third.

• Choose the base currency against your statutory reporting, and understand it is permanentThe base currency is set when the Dataverse database is created and cannot be changed afterwards. If contracts are written in US dollars or euros while statutory reporting is in Armenian dram or Georgian lari, decide which of those the system reports in before the database exists. Getting this wrong means a new environment and a full migration.
• Add every transaction currency you will ever quote in, at the startEach with its symbol and its precision. Adding one later is easy, but records already saved in the wrong currency are not, and a quote raised in the wrong currency is a commercial conversation rather than a data fix.
• Decide who maintains the exchange rate, and how oftenThe exchange rate on a currency record is a static number that somebody has to update. There is no automatic feed built in. Name the person or the flow, name the source rate you use, and write down the frequency, because an untouched rate is the default state of most environments we audit.
• Agree with finance what a base currency report actually meansBase amounts are calculated using the rate in effect when the record is written, and changing the rate later does not restate rows that already exist. A base currency total is therefore a mixture of historical rates, which is usually correct and almost never what somebody assumed. Settle it before the first board pack.
• Set currency and pricing decimal precision before any price data existsTwo decimals is fine for dram against dollar totals and is not always fine for a unit price on a low value item sold in thousands. Test the rounding against how your sales team actually quotes, at the point where it is still a setting.
• Build one price list per currency, and check the rounding rules on eachPricing method, rounding policy, and rounding option per price list item. This is standard configuration and it covers more commercial models than most teams expect, which is worth confirming before anybody scopes a pricing plug-in.
• Decide which system issues the legally valid invoiceIn Armenia and Georgia the tax invoice is issued through the state electronic invoicing system, so Dynamics 365 is the commercial record rather than the fiscal one on almost every regional project. Decide that explicitly, and decide which field carries the reference between the two, because reconciling them by hand is the workaround that never goes away.
• Model VAT treatment as data on the customer, not as knowledge in the sales teamDomestic supply, export of services, reverse charge for an EU business customer, and whether the customer is registered. A field on the account and a rule that reads it. Left as tribal knowledge, it becomes a correction after an audit.

The regional items that are invisible from a headquarters implementation guide and obvious to anyone who has run a rollout at GMT+4.

• Load the right public holidays into the business closure calendarArmenian, Georgian, and Azerbaijani public holidays are not the same list, and none of them match a default calendar. An SLA clock runs straight through a holiday nobody entered, and the first anybody hears of it is a breach report in January.
• Account for the daylight saving gap in service hours and in shared support windowsArmenia does not change its clocks. European customers do, so the overlap with a team in Yerevan moves by an hour twice a year. Write the support window in a way that survives that, and set the customer service schedule so the SLA does too.
• Set the personal data rules before there is personal dataArmenian and Georgian personal data law, plus GDPR if you sell into the EU. Decide retention, decide who may export, and decide what a deletion request actually does to a record and to its audit history. This is a design decision, not a policy document.
• Confirm the interface languages you need exist as language packsCheck the current supported language list against what you are about to promise, and decide the fallback where a pack does not exist. English and Russian cover most regional teams in practice, and it is better to say so at the start than after a demo.
• Set date, number, and currency formats per user, then test themA comma decimal separator meeting a period one is a data quality incident rather than a display preference, and it shows up in imports, exports, and anything anyone builds in Excel.
• Decide which documents must exist in which languageQuotes, invoices, and customer facing correspondence. Interface language and document language are separate decisions with separate work behind them, and only one of them is a setting.

Project Operations sits on the same Dataverse as the rest of Customer Engagement, which makes it look like one more module. The decisions below are what actually determine its cost.

• Choose the deployment type before anybody scopes the workThe lite deployment keeps the path from deal through to invoicing inside Dataverse, which suits most regional professional services firms. Deployments that connect through to a separate finance back end are a materially larger programme with a different integration, a different licence, and a different team. Choosing this in week six rather than week zero is an expensive way to find out.
• Decide the work breakdown granularity, and who maintains itActuals are only ever as good as the plan they are booked against. A hundred line schedule that nobody updates produces margin reporting that is worse than no reporting, because people believe it.
• Set up resource roles and a role price per currencyRoles, skills, and a price per role in every currency you contract in. This is where the multi-currency decisions in phase six become real, because a role price list in the wrong currency quietly misprices every estimate built on it.
• Decide chargeability by transaction class, and which expenses are never billedTime, expense, and material each need a default and a set of exceptions. The exceptions are what people argue about at invoicing, so they belong in configuration rather than in an email thread.
• Choose the billing method per contract line, not per contractFixed price with milestones for the knowable parts, time and material with a not to exceed for the rest. Exactly the split described in the fixed price against time and materials section above, applied to your own clients this time.
• Configure the time and expense approval chain, and name who chases the missing entriesThe approval chain is configuration and it takes an afternoon. The discipline is a person, and without one the whole module produces confident numbers built on half the timesheets.
• Decide how a won quote becomes a project contract, and who is allowed to do itThis is the handover point between the sales side and the delivery side, and it is where regional implementations most often end up with two versions of the same commercial agreement.
• Confirm which currency the margin report actually usesThe contract currency, the role price currency, and the base currency are three different things and they are frequently three different currencies. Ask the question before somebody presents a margin number to a board.

The last phase, and the one that decides whether the system is still trusted in month six.

• Test at realistic volume, not against twenty demo rowsWall four on this page explains why. A query written the wrong way against a large table returns an answer that is wrong rather than slow, and it looks perfect during testing precisely because the test data was small.
• Write the regression list once, and retest it every release wavePricing logic, embedded apps, code components, the flows on your key records, and every integration. The list is short, it takes an hour to write, and it is the whole difference between a managed update and a surprise.
• Enable the early release channel on the test environmentSo you meet a release wave in a place where it does not matter. This is free, it takes one setting, and almost nobody does it.
• Run acceptance testing with the people who will actually use it, against scripted scenariosReal scenarios end to end, run by the users themselves, not a walkthrough delivered to them. A user who has driven their own record through the system before go live is a different person in week one.
• Write the cutover runbook, including the rollbackWhat freezes and when, who signs off each step, what the last good state is, and how you get back to it. Written the week before, not the night of.
• Budget hypercare, then a standing support allowance for year twoConcentrated support for the first weeks, then a steady allowance from around twenty hours a month for one Customer Engagement app. It is the line most often left out of a comparison between doing it yourself and hiring, and it applies to both.
• Confirm the handover in writing before you sign anythingSource in a repository you own, solutions your own administrator can import, and documentation another developer could pick up. If a supplier cannot agree that at the start, the question of what happens at the end has already been answered.