A Dynamics 365 go live is the most stressful week in any implementation project. Months of workshops, configuration, testing and politics all come down to a single weekend where you flip the switch and pray that nothing catches fire. I have been through dozens of these now, both as the technical architect and as the poor sod on the other end of the phone at two in the morning when something breaks. Here is what I have learned about making go live survivable.
The go live is not when things go wrong. It is when you find out what already went wrong.
This is the single most important thing to understand about a Dynamics 365 go live. Every issue you encounter on go live weekend already existed in your system. You just did not find it yet. The data was already dodgy. The integration was already fragile. The business process was already unclear. Go live just shines an extremely bright light on all of it at once.
That is why the weeks before go live matter far more than the weekend itself. If you are scrambling to fix configuration on go live Saturday, something went badly wrong long before anyone started the cutover. The go live should be boring. If it is exciting, you have a problem.
Your cutover plan needs to be a script, not a document
I have seen go live cutover plans that read like a novel. Forty pages of prose explaining what needs to happen, in what order, with footnotes and appendices. These are completely useless when you are sat in a conference room at midnight with cold pizza and a room full of people who just want to go home.
Your cutover plan should be a numbered checklist. Each step should take no more than one line. It should say exactly who does it, exactly when they do it, and exactly how you verify it worked. No ambiguity. No interpretation required. Something like:
Step 14: Run data migration batch for customer records. Owner: Rob. Verify: Count matches source (expected 14,382). Estimated time: 45 minutes.
That is a step someone can execute at one in the morning without thinking too hard about it. I have written about Dynamics 365 data migration separately, but the principle applies to every step: be specific enough that a tired person can follow it without asking questions.
Do a dress rehearsal. Then do another one.
The single best predictor of a smooth go live is whether you did a proper dress rehearsal. Not a walkthrough. Not a tabletop exercise. An actual end to end execution of your cutover plan in a sandbox environment, timed, with the real people who will be doing it on the night.
The first rehearsal will be a disaster. That is fine. That is the point. You will discover that step 7 takes three hours instead of thirty minutes. You will find out that the integration credential expires at midnight. You will realise that nobody actually knows the admin password for the legacy system. Better to learn all of this on a Wednesday afternoon than on go live Saturday.
The second rehearsal should be clean. If it is not, you are not ready to go live. Full stop. I do not care what the project manager says about the deadline. I do not care what the steering committee promised the board. If your second dress rehearsal is messy, your go live will be worse. Push the date. It is cheaper than a failed go live, every single time.
Integrations will betray you
If I had to bet money on one thing going wrong during a Dynamics 365 go live, I would bet on integrations. Every time. The integration that worked perfectly in test will fail in production because the firewall rules are different, the SSL certificate is wrong, the service account does not have the right permissions, or the third party vendor decided to deploy an update on Friday afternoon without telling anyone.
For every integration, you need a fallback plan. What happens if the integration between Dynamics and your warehouse system goes down for four hours? Can the business operate manually? Who does what? Where do they record the transactions that need to be replayed later? If you cannot answer those questions before go live, you are gambling.
I always insist on having direct contact details for the technical lead on every integrated system. Not a support desk. Not a ticketing system. A mobile phone number for someone who can actually fix things. On go live weekend, you do not have time for a support queue. You need someone who picks up the phone and says yes, I will fix it now.
Data migration is where implementations go to die
I have covered data migration in detail before, but it deserves repeating in the context of go live. The most common cause of go live failure I have seen is bad data. Not missing data. Bad data. Duplicate customers, invalid postcodes, orphaned records, dates that do not make sense, status codes that do not map to anything in the new system.
Your data migration should have been validated at least three times before go live weekend. Each validation should include a reconciliation step where you compare counts and key figures between the source and target. If the numbers do not match, stop and fix it before moving on. The temptation is always to push through and deal with data issues after go live. Do not do this. Data problems after go live affect real users doing real work, and fixing them under pressure is ten times harder than fixing them in a sandbox.
Staff your go live like you expect problems
The worst go lives I have been involved with had skeleton crews. One developer. One consultant. A project manager who was also covering two other projects. When something went wrong, and something always goes wrong, there was nobody available to fix it because the one person who knew that area was already fixing something else.
A proper go live team should include your technical architect, at least two developers, a functional consultant for each major workstream, someone from the business who can make decisions without escalating, and someone whose only job is to update the status tracker and keep everyone informed. That last role sounds trivial but it is actually critical. During a go live, communication failures cause more damage than technical failures.
If you are doing Dynamics 365 consulting, make sure your go live support is properly scoped and staffed from day one. I have seen too many projects where go live support was an afterthought bolted on at the end, and the result is always the same: chaos.
Have a rollback plan and actually test it
Every go live needs a point of no return. Before that point, you can roll back to the old system and try again another day. After that point, you are committed. Everyone involved needs to know exactly when that point is and what the criteria are for triggering a rollback.
The criteria should be objective, not subjective. Not "if things are going badly" but "if data migration has not completed by 06:00 Sunday" or "if more than three critical integrations are failing". Subjective criteria lead to arguments at three in the morning when everyone is exhausted and nobody wants to be the person who calls it off.
And for the love of everything, actually test your rollback procedure. I have been on a project where the rollback plan was to restore a database backup, except nobody had verified that the backup was actually restorable. They found out it was not at four in the morning. That is not a situation you want to be in.
The first Monday is the real go live
You can have a technically perfect cutover weekend and still have a terrible go live. Because the real test is not whether the system works. It is whether people can use it. Monday morning is when 200 users log in for the first time and try to do their actual jobs in a system they have only seen in training sessions three weeks ago.
Floor walkers are essential. These are people who physically sit with the users on day one and help them through the basics. Not IT support waiting for tickets to come in. Actual humans walking around the office, watching people struggle, and helping them before they get frustrated enough to start complaining to their manager about how the old system was better.
I always recommend having a war room for the first week after go live. A physical or virtual space where all the key people are available instantly. Issues get triaged in real time, fixes get deployed the same day, and the business can see that problems are being dealt with. The worst thing you can do after go live is go quiet. Silence breeds resentment.
Document everything, especially the things that went wrong
After the dust has settled, do a proper lessons learned session. Not the sanitised version that goes into the project closure report. The real one, where you write down what actually happened, what caught you off guard, and what you would do differently. This is not about blame. It is about making the next go live better than this one.
If you are working with a consultancy, insist on this. Good partners will welcome it. Bad ones will try to skip it because they do not want their mistakes on record. That tells you everything you need to know about whether to use them again.
Every go live teaches you something. The question is whether you are willing to write it down and learn from it, or whether you would rather pretend it was smooth and repeat the same mistakes next time. I have made enough of these mistakes myself that I would rather be honest about them and help someone else avoid the same pain.
If you are planning a Dynamics 365 implementation and want someone in your corner who has been through the go live fire more times than is probably healthy, get in touch. I would rather help you prepare properly than get the panicked call at midnight.
