What it takes to ship a clean Workday launch, from kick-off to day 90

Two threads run through every launch that lands cleanly. The team knew what to avoid before they started. And the sponsor backed the discipline when it would have been easier not to. Neither of those is heroic. They show up as twelve specific calls, spread across the project. None of them on their own is a launch-saver. Together they are most of the work.

Phase 1 — What you set up at kick-off

1. Customisation principles, signed by the sponsor

Every customer wants their Workday to be special. Every customer overestimates which of their processes are genuinely differentiating, and underestimates which policies could change to fit the system. Each custom build adds to maintenance, slows future releases, complicates upgrades. Six months in, the team is fighting their own configuration more than they are solving business problems.

Write down the principles that decide when to deviate from standard. Have the sponsor sign them. Then repeat them in every steering meeting. The principles only do their job when the sponsor backs them against the senior leader pushing for an exception that is not in the document.

2. Named owners for change, data, and testing

Three roles that the project quietly assumes someone will pick up, and that decide whether the launch lands cleanly.

Change lead. Someone with experience running adoption on a transformation this size. Internal or external, but experienced. They embed with each workstream from day one to understand what is actually changing, not what the slide deck says. Senior leaders own adoption, the change lead drives it.

Data migration owner. Someone with real Excel depth, deep legacy system knowledge, and protected time. You will run multiple migration cycles. Spend the effort on validation, not just transformation. Make sure your partner gives you the right reports.

Test manager. Someone experienced enough to design scenarios that match how the business actually uses the process, not just standard scripts. They set entry and exit criteria per cycle, protect tester time from BAU interruptions, and put testers in the same room as the experts who can answer questions in real time.

3. An honest capacity plan against BAU

The team is being asked to build a rocket while flying the plane. They are still running payroll, supporting users, and now launching Workday. The result, unaddressed, is delays, burnout, and shortcuts that show up in year two.

Be honest about capacity, week by week, before kick-off. Plan backfill for the BAU roles that get hit hardest. Bring in temporary contractors where it makes sense, but do not hand off too many critical roles to temps either. Make the resource picture shared with your partner. Adjust early when people get overstretched. The teams who protect their people's time finish on time. The teams who run on heroics finish late and lose people in the months after.

Phase 2 — What you tighten in the final weeks

4. Real data confidence, not data theatre

If users see broken or missing data on day one, trust drops that day and does not come back. Every iteration of your prototype should include targeted data validations. Define exit criteria for both breadth (coverage across workers, jobs, comp, org structure, time) and depth (granularity and accuracy). Tighten the thresholds with every round.

If you do not meet exit criteria in a round, the mitigation plan kicks in straight away. Named owner. Date by which the data has to be at acceptance levels. No "we will keep going and fix it later". Set up semi-automated validation from day one of the build. The teams that wait until final prep to think about validation always run out of time.

5. Managers prepared as first-line support

Managers are the people closest to the change. If they do not know what is coming, they become blockers instead of enablers. Confused managers create frustrated employees, and the support tickets escalate to HR before anyone has had a chance to look at them.

Loop them in early. Hands-on training, not a webinar. A manager-specific kit with quick FAQs, escalation paths, and a sample kickoff message they can share with their team. The goal is for them to look prepared even on the days they are still figuring it out themselves. When something goes wrong on day three, a prepared manager raises it constructively. A blindsided manager complains.

6. Superusers used as influencers, not just testers

Most projects under-use their superusers. The default treats them as backup testers. Treat them as change agents instead. Pick them for credibility, not availability. Give them early access, the roadmap, behind-the-scenes context. Make them the voice of the user.

Something small that works: a recognition gesture at launch. Some teams use T-shirts, others a named-recognition note from the sponsor. Cheap, symbolic, and it pays back in adoption. The same superusers are usually the right people for on-the-ground support in the first few weeks after launch, when users are deciding whether the new system is going to work for them.

7. Testing that proves the design, not testing as a tick-box

Someone clicks through a few standard tasks. Everything looks fine. Then go-live hits and the team finds the issues that should have been caught in testing. Testing is not about clicking. It is about proving the design holds up in real-life situations.

Build detailed scenarios that match the business, not standard scripts. Assign the experienced test manager from item 2. Set entry and exit criteria per cycle. Put testers next to the people who can answer questions in real time. Protect their time. Testing means testing.

8. A real freeze period and a Change Exception Log

Last-minute changes break things, often without most people noticing until something downstream fails. One urgent tweak two weeks before launch can undo weeks of testing.

Define a formal freeze, typically two to four weeks before go-live, and hold it. Only business-critical changes get through, and even those follow a risk-based approval path. A Change Exception Log forces any late ask to justify the business risk of not doing it. The log protects your team. It also gives executives visibility into what is at stake when they push for late changes, which usually slows the asks naturally.

9. A cutover plan and a single cutover owner

A cutover plan is not a high-level Gantt chart. It is a minute-by-minute schedule of who does what, when, and with what fallback. The format that works is a single detailed spreadsheet covering the weeks either side of launch, with named owners on every line.

One person owns the timeline. Not the program manager. Not the partner lead. A cutover manager whose only job for those four weeks is to keep everyone aligned and make real-time decisions when things shift. Daily cutover standups start at least a week before launch. Open items get tracked, blockers get called out, nothing is assumed. Small issues stay small when someone is watching.

Phase 3 — What you have ready for day one and after

10. A day-2 support model designed before launch

Go-live is not the finish line. If users do not know where to go for help, or get conflicting answers depending on who they ask, the trust you built before launch evaporates in a week.

What clear looks like in practice. A documented support structure from day one. Named owners for ticket triage, routing, the boundary between bug and enhancement, and SLAs on response and resolution. Internal versus vendor responsibilities written down, not assumed. A model that scales past hypercare, because the support burden does not drop to zero in week three. On-the-ground support for HR operations during the first weeks calms nerves and reinforces confidence at the moment it matters.

11. A day 30 / 90 / 180 roadmap shared before launch

Without a post-launch plan, momentum fades. Fixes drag. Enhancements stall. Map the next six months before launch, not after. Day 30 for stabilisation. Day 90 for enhancements and the items that were deferred. Day 180 for the first strategic improvements based on real usage.

Share it with stakeholders before launch. It sets expectations and builds patience for the things that will not be perfect on day one. Teams that walk into hypercare without a visible 180-day plan create their own panic.

12. The sponsor stays in the room

The sponsor who showed up at kick-off, steering, and the launch celebration is the same sponsor you need at month four when the backlog has grown and the business wants to know what comes next. Lock in the continued involvement before launch. Agree the cadence of the post-launch steering committee in advance. Monthly for the first three months, quarterly thereafter. Same sponsor, same forum, same metrics.

Teams who do this keep their executive air cover for the year after launch. Teams who let the sponsor drift end up rebuilding the executive story from scratch in month six, with less goodwill than they had on day one.

What clean looks like at week two

Two weeks after launch, the picture is already visible. Support ticket volume is trending down rather than flat. The data issues that did surface on day one are being tracked and closed. Managers are using the language of the new system, not asking for the old one. Superusers are still engaged. The day-2 model is being followed rather than bypassed. And the sponsor is still in the room. None of this is perfect on its own. Together they are how you know the launch landed.

What the teams who get to week two looking like this have in common is unglamorous. They made the twelve calls above on time. They did not wait until the final weeks to find out their data was not ready. They did not assume the sponsor would still be engaged. They wrote the day-2 model before they wrote the launch announcement. That ordering is most of the difference.