Dynamics 365 Go-Live Checklist: Cutover Planning & Hypercare Execution

Pre-Go-Live Readiness Assessment

The 4–6 weeks before go-live are the most critical period in your entire implementation. This is when you validate that Dynamics 365 is truly ready to become your system of record. Readiness assessments separate organizations that go live smoothly from those that experience critical post-launch fires.

Readiness Gate Checklist

Executive & Governance

• Steering Committee approved go-live date with documented risk assessment
• Executive sponsor made public commitment to go-live (broadcasts, all-hands messages)
• Project governance structure locked: escalation paths, decision rights, risk committee
• Budget for hypercare and extended support approved and allocated
• Go / No-Go decision criteria defined (e.g., UAT pass rate ≥95%, data quality ≥99%, critical integration tests green)

Organization & Change Readiness

• Training completion rate ≥95% for target user population
• Change champion network activated and trained
• Support team (help desk, super-users) trained and scheduled for hypercare shifts
• User feedback from training surveys reviewed; concerns addressed
• Communication plan executed through final week (town halls, email updates, FAQs)
• Legacy system decommissioning plan documented (when systems turn off, who owns them during parallel period)

System Readiness

• UAT sign-off completed by business process owners (not just IT)
• All critical defects fixed and retested; remaining issues documented with approved mitigation plans
• Performance testing completed under production-like load; response times acceptable
• Security testing completed; vulnerabilities remediated
• Accessibility testing completed for users with disabilities
• All customizations, extensions, and third-party integrations tested in UAT environment
• Disaster recovery and backup procedures tested and validated
• Production environment built, documented, and hardened
• Microsoft FastTrack Go-Live Readiness Review completed (required for Dynamics 365 Finance, Supply Chain Management, Human Resources, and Project Operations implementations): submit answers in the Dynamics 365 Implementation Portal no later than four weeks before your target go-live date. New projects must use the Implementation Portal—Lifecycle Services (LCS) project creation is frozen for new customers. AI-assisted reviews may complete same-day; manual reviews can take up to three business days plus any additional risk-mitigation time. Production environment deployment cannot be triggered until this review is successfully completed.

Data Readiness

• Master data (customers, vendors, GL accounts, products) validated and loaded in production
• Historical data migration tested end-to-end; reconciliation completed
• Data quality metrics published; target accuracy ≥99% for critical data
• Opening balances (GL, AP, AR, Inventory) verified against legacy system audited records
• Data migration scripts locked (no ad-hoc changes after UAT)

Cutover Readiness

• Detailed cutover playbook documented and reviewed with project team
• Cutover roles and responsibilities assigned (cutover lead, data lead, comms lead, support lead)
• Cutover schedule validated with IT operations, network, and database teams
• Rollback procedure documented and tested (or approved decision to not rollback)
• Communication plan for go-live day finalized (email templates, town hall agenda, support messages)

If any item is red, address it explicitly or escalate to the Steering Committee. Do not proceed with go-live if multiple readiness items are incomplete.

Data Validation Checklist

Data quality is the #1 cause of post-launch firefighting. Spending 3–4 weeks on data validation prevents months of downstream issues.

Master Data Validation

Customer Master

• All active customers loaded; count matches legacy system
• Customer IDs unique; no duplicates
• Addresses complete (billing, shipping); postal codes valid (postal code lookup validation)
• Tax IDs present for customers requiring them; format valid
• Credit limits set and approved by Credit department
• Payment terms mapped from legacy to Dynamics 365; terms are valid
• Default pricing and discounts populated; match legacy rates
• Customer contact information populated; no missing email addresses
• Inactive customers marked appropriately (don’t allow new orders)

Vendor Master

• All active vendors loaded; count matches legacy system
• Vendor IDs unique; no duplicates
• Remittance addresses complete and validated
• 1099 / Tax ID information populated and valid
• Payment methods set (check, ACH, wire); bank details validated
• Payment terms mapped and valid
• Standard costs or pricing populated where required
• Contact information present; escalation contacts defined
• Vendor compliance status (insurance, certifications) verified

Product / Item Master

• All active products loaded; inactive items marked appropriately
• Item IDs unique; no duplicates or cross-references that break logic
• Description, UOM (unit of measure), and category correct
• Standard costs loaded and match legacy inventory value
• Pricing (list price, standard cost, landed cost) validated against legacy
• Bill of materials (if applicable) loaded and tested
• Lot / Serial number requirements set correctly
• Discontinued items marked; don’t allow transactions

Chart of Accounts

• All GL accounts created and active status correct
• Account numbers match legacy numbering or mapping documented
• Account type (Asset, Liability, Equity, Revenue, Expense) correct
• Main accounts (P&L, Balance Sheet) separated from sub-accounts correctly
• Consolidation accounts marked; elimination logic defined
• Intercompany accounts created if multi-entity

Transactional Data Validation

Opening Balances

• GL opening balances (by account) reconcile to legacy trial balance, audit-confirmed
• AR aging (by customer) matches legacy sub-ledger; dollar amounts exact
• AP aging (by vendor) matches legacy sub-ledger; dollar amounts exact
• Inventory balances (quantity & value) match physical counts and legacy valuation
• Fixed asset registers loaded; depreciation schedule validated
• Bank reconciliation items (outstanding checks, deposits in transit) identified and documented

In-Flight Transactions

• Open purchase orders loaded; PO dates, amounts, and line items match legacy
• Open sales orders loaded; quantities and dates correct
• Unapplied cash (customer overpayments, vendor prepayments) identified and posted to GL
• Accruals and deferred revenue validated; amounts match legacy
• Goods-in-transit and consignment inventory recorded correctly

Data Validation Metrics

• Master data accuracy: ≥99.5% of records pass validation (identify and fix exceptions)
• Opening balance reconciliation: 100% match to legacy system (to the penny)
• Transaction completeness: ≥99% of legacy transactions successfully migrated
• Duplicate rate: <0.1% (identify and consolidate or delete)
• Missing critical fields: <0.5% (address before go-live)

If any metric falls below target, do not proceed. Address exceptions and retest.

Integration & Interface Verification

Dynamics 365 rarely stands alone. It integrates with legacy systems, third-party applications (shipping, accounting, reporting), and custom middleware. Interface failures are a leading cause of go-live chaos.

Interface Testing Checklist

For Each Interface / Integration:

• Interface documented: source system, target system, frequency (real-time, batch, manual), data volume expected
• Load testing completed: interface tested with production-like volume (e.g., 1,000 customers, 10,000 transactions)
• Error handling defined: what happens if interface fails? Manual workaround? Retry logic? Alerting?
• Data mapping validated: every field mapped correctly; business rules (e.g., invoice date = transaction date) enforced
• Reconciliation process defined: how do you validate interface completeness? Weekly reconciliation report?
• Rollback scenario tested: if interface fails on go-live day, what’s the recovery path?
• Owner identified: who owns the interface post-launch? Who gets paged if it breaks?

Common Integrations to Verify:

• Legacy ERP → Dynamics 365 (initial data migration)
• Dynamics 365 → General Ledger (consolidated reporting system)
• Dynamics 365 ↔ CRM / Sales Cloud (if using Dynamics 365 Sales & Marketing)
• Dynamics 365 ↔ HR system (employee, payroll data)
• Dynamics 365 → Warehouse Management System (if applicable; inventory, shipments)
• Dynamics 365 → EDI system (customer orders, shipment notifications)
• Dynamics 365 → Payment gateway (credit card processing for sales orders)
• Dynamics 365 → Business Intelligence / Data warehouse (reporting extracts)
• Dynamics 365 → Email system (automated order confirmations, invoice delivery)

Integration Go-Live Readiness

• All critical interfaces (those that impact day 1 business) tested and passed with green status
• Non-critical interfaces (those that can be manual for week 1) identified and documented
• Alternative manual processes defined for critical interfaces if they fail on go-live
• Support escalation path for interface failures: who to call, how quickly to respond?
• Monitoring and alerting in place: proactive detection of interface failures, not reactive discovery by end users

Security & Access Control Review

Security oversights on go-live often aren’t discovered until weeks later (e.g., “Why can the clerk in Accounting see the CEO’s payroll?”). Validate before launch.

User Access Verification

• User account provisioning complete: all target users have accounts and passwords set
• Role assignment correct: each user assigned to appropriate role(s) for their job function
• Access level appropriate: does the user see only data they should? Segregation of duties enforced?
• Privileged access audited: are there excessive admins? Are admin accounts used for day-to-day work (red flag)?
• Inactive user accounts disabled: no legacy employee accounts still active
• Third-party / vendor access granted only to systems they need; time-limited if applicable

Segregation of Duties (SoD) Validation

Segregation of duties prevents fraud. An individual should not be able to create a vendor, approve payment, and process payment without oversight.

• Purchase-to-Pay process: Creation, Approval, Receipt, Invoice matching, Payment processed by different individuals
• Order-to-Cash process: Customer creation, Sales order entry, Shipment, Invoice generation, Cash receipt processed by different individuals
• General Ledger: Journal entry creation, approval, posting, and reconciliation performed by different people
• Inventory: Physical count, system adjustment, cost variance investigation done by different people
• SoD conflicts documented: if business process requires someone to have conflicting access, exception approved by CFO in writing

System Security Configuration

• Password policy enforced: complexity, expiration, lockout after failed attempts
• Multi-factor authentication (MFA) via Microsoft Entra ID enabled for all users. Microsoft now mandates MFA for Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center sign-ins (phased enforcement began October 2024), as well as Microsoft 365 admin center sign-ins (phased enforcement began February 2025). Configure Conditional Access policies to enforce MFA for Dynamics 365 environment access as well.
• API keys and integration credentials secured (not hard-coded in scripts; stored in Azure Key Vault or equivalent)
• Audit logging enabled: user logins, data access, sensitive transactions logged
• Change controls in place: system changes require approval, documented, and tested before production
• Backup encryption enabled: data encrypted at rest and in transit
• Network security validated: firewall rules, VPN access, IP allowlisting configured

Performance & Load Testing

Performance issues discovered on go-live day are catastrophic. Users can’t do their jobs; workarounds emerge; support is overwhelmed. Test under load before launch.

Performance Testing Scope

• Load test defined: simulate expected number of concurrent users, transactions per hour, data volume
• Peak load identified: when is your peak usage? (e.g., month-end close, order entry before cutoff, payroll processing)
• Response time baseline established: what’s acceptable? (e.g., <3 seconds for typical transaction, <10 seconds for complex reports)
• Load test executed with realistic scenarios: not just login tests, but actual business processes (create PO, receive goods, process invoice, post payment)
• Database performance validated: indexes in place, query plans optimized, no full table scans
• Report performance tested: key reports (aging reports, GL trial balance, inventory valuation) run acceptably on first day of month
• Integration performance validated: batch interfaces complete in acceptable time (e.g., nightly GL post completes by 6 AM)

Load Test Results & Acceptance

• Response times meet baseline: 95th percentile response time < acceptable threshold
• No errors under load: error rate <0.1%
• Database CPU and memory acceptable: utilization <80% under peak load (headroom for spikes)
• Storage capacity adequate: available disk space ≥30% of total (growth buffer)
• Bottlenecks identified and remediated: if any component is the constraint, optimization completed

Backup & Rollback Plan

Hope for the best; plan for rollback. A well-documented rollback procedure prevents panic-driven decisions that make situations worse.

Backup Strategy

• Full database backup completed and tested (restore-to-point-in-time validated)
• Backup retention defined (e.g., daily backups for 30 days, weekly for 1 year)
• Backup testing scheduled: monthly restore tests to validate backup integrity
• Backup location: offsite or secondary region (protection against data center failure)
• Backup encryption: backups encrypted at rest
• Recovery Time Objective (RTO) defined (e.g., restore within 4 hours)
• Recovery Point Objective (RPO) defined (e.g., lose max 1 hour of data)

Rollback Decision Criteria

Define the conditions under which you would rollback (vs. pushing forward and fixing issues). Examples:

• Automatic Rollback: Critical GL posting interface fails and can’t be restored within 2 hours; data integrity at risk.
• Executive Decision (within 24 hours): >30% of users unable to perform core transactions; no workaround path identified.
• No Rollback Option: Data corruption discovered 72 hours post-launch (too late to safely rollback; must move forward and fix).

Document the decision criteria, who has authority to decide, and the escalation path.

Rollback Procedure (if applicable)

• Rollback steps documented: stop applications, restore database from pre-cutover backup, validate legacy system state, resume business on legacy system
• Data loss assessment: what transactions entered in Dynamics 365 will be lost if we rollback? How do we capture and replay them in legacy system?
• Rollback timeline: how long will rollback take? (Usually 2–8 hours depending on database size and backup restoration speed)
• Communication plan: how will you inform users, partners, and regulators of the rollback?
• Rollback testing: test the restore process in a pre-production environment to validate it works and estimate timing

Cutover Sequence & Data Refresh

A detailed cutover playbook is your roadmap for go-live day. It removes ambiguity and lets the team execute under pressure.

Cutover Playbook Components

• Timeline: Hour-by-hour schedule from legacy system shutdown through Dynamics 365 validation and handoff to business operations.
• Parallel Testing Window (if applicable): Hours when you’re running old & new system in parallel, validating reconciliation.
• Final Data Refresh: Time when the final data extraction from legacy system is completed, transformation applied, and loaded into Dynamics 365.
• System Startup Sequence: Order in which Dynamics 365 components start (DB, web services, batch jobs, integrations).
• Validation Gates: Checkpoints where you verify success before proceeding (e.g., “GL balances match legacy trial balance before declaring Finance ready”).
• Stakeholder Sign-offs: Who declares each module ready? CFO for Finance; VP Supply Chain for Procurement; VP Sales for Sales module.
• Escalation Procedures: If a gate fails, what’s the path? Immediate fix? Wait for next cycle? Partial go-live?

Sample Cutover Timeline (Big Bang, Single-Day Cutover)

Friday 8 PM:   Stop all user activity in legacy system. Final GL posting freeze.
Friday 8:30 PM: Database backup of legacy system (safety copy).
Friday 9 PM:   Final data extraction: GL, AR, AP, Inventory, PO, Sales Orders.
Friday 10 PM:  Data transformation (mapping, validation rules, GL consolidation).
Friday 11 PM:  Load data into Dynamics 365 Production DB.
Saturday 12 AM: Parallel testing begins. Finance team validates GL, AR, AP balances. Supply Chain validates Inventory, PO balances.
Saturday 2 AM:  All balances reconciled. Gate 1 (Data Validation) PASSED.
Saturday 3 AM:  System interfaces enabled (EDI, payroll feeds, reporting extracts). Integration testing.
Saturday 4 AM:  All interfaces green. Gate 2 (Integration) PASSED.
Saturday 4:30 AM: Legacy system decommissioned. Read-only mode disabled. System shutdown.
Saturday 5 AM:  Users notified: Dynamics 365 is live. Support desk opens.
Saturday 6 AM:  Wave 1 users (Finance) log in, validate transactions, begin limited processing.
Saturday 10 AM: Wave 1 sign-off. Finance director approves Finance module ready.
Saturday 12 PM: Wave 2 users (Supply Chain) log in, validate processes.
Saturday 4 PM:  Wave 2 sign-off. VP Supply Chain approves module ready.
Saturday 6 PM:  All waves live. Cutover complete. Hypercare support stands up.

Parallel Testing Window Details

If running parallel (old & new system 2–4 weeks):

• Daily nightly batch: GL transactions from Dynamics 365 loaded back to legacy system (or vice versa)
• Daily reconciliation: Finance team compares GL balances, AR aging, AP aging. Investigate variances.
• Weekly reconciliation sign-off: document that balances match or identify acceptable differences (timing differences, in-transit items)
• Cutover decision gate: after 2–4 weeks, when confidence is high, leadership approves switch-off of legacy system

War Room Setup & Support Structure

The war room is the nerve center of go-live. It’s where issues are identified, escalated, and resolved in real-time.

War Room Physical Setup

• Location: Dedicated space (conference room or temporary office) with phones, internet, screens, whiteboards. For distributed teams, a persistent Microsoft Teams or Slack channel with video bridge serves the same purpose.
• Hours: 24/7 for first 48 hours if cutover is continuous. Then shift to 24/5 (nights + weekends skeleton crew) for weeks 1–2, then business hours + on-call for weeks 3–4.
• Staffing: Project Manager (overall coordinator), Technical Lead (database, infrastructure), Finance Lead (GL, AR, AP), Supply Chain Lead (POs, Inventory), and so on by module.
• Communication: Dedicated phone line, Teams/Slack channel, email distribution. Predefined escalation phone numbers posted on wall or pinned in channel.
• Supplies: Coffee, energy drinks, snacks. (Hypercare is stressful; fuel the team.)

Support Desk Structure

• Tier 1: Help desk staff, first call for user issues. Handle common questions, password resets, training refreshers. Target: resolve 70–80% of tickets within 1 hour.
• Tier 2: System specialists, module-specific expertise (Finance specialist, Procurement specialist). Escalated from Tier 1 for complex issues. Target: 2–4 hour resolution.
• Tier 3: War Room team (architects, technical leads, business process experts). Escalated from Tier 2 for critical issues. Target: <30 minute response, all-hands on deck.

Ticketing & Escalation Process

• Support ticketing system configured and staffed (ServiceNow, Jira, or similar)
• Severity levels defined: P1 (critical, >50 users affected or data integrity at risk) → immediate escalation to war room. P2 (high, 5–50 users) → Tier 2 within 30 min. P3 (medium) → Tier 1 workaround or scheduled Tier 2 fix. P4 (low) → backlog.
• Escalation template: issue description, affected users, business impact, attempted resolution, escalation time
• War room decision tree posted: if issue is X, escalate to Y; if issue is Y, escalate to Z

The Critical First 48 Hours

The first 48 hours post-launch determine whether you’re heading toward success or chaos. Vigilance and rapid response are critical.

Hour 0–4: System Stability Verification

• Dynamics 365 application servers running, responding to requests
• Database accessible, queries executing normally
• Critical integrations (GL posting, EDI, payroll) operational; no failed jobs
• Security and access working: users logging in successfully, role-based permissions enforced
• War room operational: Teams/Slack channels active, escalation phone line staffed, status board updated

Hour 4–12: Wave 1 Execution

• Finance / Accounting begins critical month-end processes (if cutover is mid-month) or transactional processing (invoicing, payments)
• Monitor transaction volume: are invoices being processed? Payments submitted?
• Track issues: common themes emerging? “Users can’t find the Approve Invoice button.” (training gap) vs. “Payment module crashes when processing” (bug).
• Provide real-time coaching: Tier 1 help desk actively calling out to users, not just waiting for tickets. “Hi, how’s it going? Need help with anything?”
• Publish first status update to stakeholders (email or Teams post): system status, issue count, resolution progress

Hour 12–24: Stabilization & Monitoring

• First batch cycle completed (nightly GL post, inventory valuation, reporting extract). Validate results.
• Integration health check: all interfaces ran successfully? Any data discrepancies?
• Issue trend analysis: are new issues declining? Are the same issues recurring (systemic problem)?
• User sentiment check: quick pulse survey or informal check-ins. Are users frustrated? Confused? Confident?
• War room shift change: brief incoming team, hand off open issues, update status board

Hour 24–48: Confidence Building

• Second business day processing: full transaction volume expected. Monitor for performance degradation.
• End-of-day reconciliation: GL balances, bank reconciliation, AR/AP aging match expectations
• Executive status update: formal briefing to Steering Committee. Go-live status, issue summary, risk assessment, hypercare plan confirmation.
• Begin planning transition from war room to steady-state support (target: end of week 2)
• Document lessons learned while they’re fresh: what went well, what didn’t, what to improve for next phase or rollout

Hypercare Plan: Weeks 1–4

Hypercare is the structured support period immediately following go-live. It bridges the gap between project team support and steady-state IT operations.

Hypercare Structure

Week	Support Hours	Staffing	Focus
Week 1	24/7 (or extended hours)	Full project team + support desk	Stabilization, critical issue resolution, user coaching
Week 2	Extended business hours + on-call	Core project team + support desk	Issue resolution, process optimization, training reinforcement
Week 3	Business hours + on-call	Reduced project team + support desk	Knowledge transfer to IT operations, documentation updates
Week 4	Business hours	IT operations + on-call project team	Transition to steady-state, hypercare exit criteria validation

Hypercare Exit Criteria

Do not exit hypercare until these criteria are met:

• P1 and P2 issues resolved or have approved workarounds with fix dates
• Daily transaction volume at or above expected levels (users are actually using the system)
• Month-end close completed successfully in Dynamics 365 (if applicable)
• All critical integrations running without manual intervention
• IT operations team trained and capable of supporting the system independently
• Knowledge base articles created for top 20 support issues
• User satisfaction survey completed; results reviewed by Steering Committee
• Formal hypercare exit approved by Steering Committee

Post-Hypercare Transition

• Support ownership transferred from project team to IT operations / managed services
• SLA (Service Level Agreement) defined for ongoing support: response times, resolution targets, escalation paths
• Ongoing optimization backlog created: items identified during hypercare that improve the system but aren’t critical
• Quarterly business review scheduled: assess system performance, user adoption, optimization opportunities
• Continuous improvement process established: how do users request enhancements? How are they prioritized and delivered?

Common Go-Live Pitfalls & How to Avoid Them

Pitfall	Impact	Prevention
Skipping dress rehearsal cutover	Unexpected issues on go-live day; timeline blown	Run at least one full mock cutover 2–4 weeks before go-live
Incomplete data validation	Wrong balances, missing customers, duplicate vendors	Dedicate 3–4 weeks to data validation; reconcile to the penny
Undertrained users	Help desk overwhelmed; users revert to spreadsheets	95% training completion; hands-on labs, not just slide decks
No rollback plan	Panic decisions if critical issues arise	Document and test rollback procedure; define decision criteria
Ignoring change management	User resistance, low adoption, shadow systems	Executive sponsorship, change champions, continuous communication
Going live during peak business period	Compounded stress; higher risk of business disruption	Choose a low-volume period (avoid month-end, quarter-end, peak season)
Skipping FastTrack Readiness Review	Production environment deployment blocked; go-live delayed	Submit Implementation Portal answers at least four weeks before target go-live

Go-Live Communication Templates

Pre-Go-Live Announcement (1 Week Before)

Subject: Dynamics 365 Go-Live — [Date] — What You Need to Know

Team,

We are on track to go live with Dynamics 365 on [Date]. Here’s what you need to know:

• Legacy system access: [Legacy System] will be available in read-only mode until [Date]. After that, all work moves to Dynamics 365.
• Training: If you haven’t completed your training, please do so by [Date]. Contact [Training Lead] for assistance.
• Support: Starting [Go-Live Date], contact the help desk at [phone/email/Teams channel] for any Dynamics 365 questions.
• What to expect: The first few days may feel different. That’s normal. Our support team is standing by to help you.

Thank you for your patience and commitment to this transition.

[Executive Sponsor Name]

Go-Live Day Announcement

Subject: Dynamics 365 Is LIVE — Welcome to Our New System

Team,

Dynamics 365 is now live! You can access the system at [URL].

• Login: Use your Microsoft Entra ID credentials (same as your Microsoft 365 login).
• Need help? Contact the support desk at [phone/email/Teams channel]. We have extended support hours this week.
• Quick reference guides: Available at [link to documentation/SharePoint site].

Thank you for making this transition possible. Let’s make it a success together.

[Project Manager Name]

Daily Status Update (Hypercare Period)

Subject: Dynamics 365 — Day [X] Status Update

• System Status: [Green / Yellow / Red]
• Open Issues: [X] P1, [X] P2, [X] P3
• Resolved Today: [X] issues
• Key Wins: [e.g., “First invoice batch processed successfully”]
• Known Issues: [Brief description of top issues and expected resolution]
• Action Needed: [Any user actions required]

Next update: [Tomorrow at X AM]

[Project Manager Name]