The Thrillworks Pre-Kickoff Checklist

If we could influence one variable on a project, it would be this one. Not budget, not timeline, not technology. A project with a decisive, available, trusted product owner consistently outperforms a better-funded project without one. The failure mode is not a bad decision; it is not a decision, repeated weekly.

Sequence is a strategic decision disguised as a scheduling one. Going first should be earned by whichever part of the organization will most usefully stress-test the model, not by whoever asked loudest.

This decision shapes almost everything downstream: the content model, the search migration, redirect mapping, analytics, and how tenancy is architected. It is also political, which means it takes longer to settle than it does to implement. Start it early.

Two genuinely different things get called a design system. One is brand expression: colour, type, photography, page compositions. The other is the component system: every building block, its variants, its states, its accessibility requirements, and what an author is permitted to assemble. In any platform with more than one site, the second is effectively your content model in visual form. The common failure is that a creative partner delivers a beautiful set of page designs, everyone calls it a design system, and the implementation partner quietly reverse-engineers a component system out of comps under deadline, with no budget for it. The risk is not that the wrong party owns this work. It is that nobody does.

Translation means saying the same thing in another language. Localization means the content genuinely differs because the audience does. Treating the second as the first is how multilingual programs quietly fail, and the difference has to be designed into the content model rather than discovered during authoring.

Residency is one of the most common late-stage blockers in platform selection, and most of the anxiety dissolves once someone maps what data actually lives where. In a headless architecture the CMS typically holds published content only, never customer or member records. That does not make the policy question disappear, but it usually converts a blocker into a scoping exercise. Do that mapping before it becomes an escalation.

This is the single biggest lever on total cost, and it is the one most often left ambiguous until a change order. Organizations frequently discover that what they called "twelve sites" is really twelve sites plus ninety sub-organizations who all believe they are included. Draw the line in writing, and handle everything below it as directory entries rather than managed properties.

Tier determines both capability and the service level a partner can responsibly promise. It is worth resolving before anyone commits to an uptime number in a proposal.

Content volume is the largest unknown in most replatforms and the reason migration estimates are so often wrong. But raw page count matters far less than structure. Ten thousand well-modelled entries can move almost automatically. Two thousand pages of hand-built HTML cannot, because a person has to read each one and decide what it actually is. Even a rough count, with a note on how structured the source is, converts a guess into a range.

Front-end schedules depend on this handoff being complete, implementable and on time, and it is usually the dependency the delivery partner controls least. The specific question worth asking: is what is coming a component system, or a set of page designs?

The first question in any integration estimate is whether the other system has a documented, supported, public API. If it does not, you are not scoping an integration; you are scoping a small product with ongoing maintenance. Those are very different budgets, and finding out in month four is expensive.

Almost every organization owns more digital property than any single person has a list of. Each one is either in scope, explicitly out of scope, or a surprise. Only two of those are good.

You cannot demonstrate that search performance and conversion were protected through a migration without a "before" to compare against. Capturing it afterwards is not possible, and this is the single most common regret we hear post-launch.

This becomes your permissions model. Gathering it early almost always surfaces something useful, usually that several people have publishing access nobody realised they still had.

Accessibility is far cheaper designed in than retrofitted, and knowing your starting position prevents a new build from inheriting old problems. If a previous audit exists, the partner should see it before design starts, not after.

These become validation rules, field requirements and authoring guidance inside the platform. Standards that live in a PDF get ignored. Standards built into the content model get followed by default.

In any federated or multi-business-unit organization, nothing damages a rollout faster than a team learning about it second-hand. The technical work is rarely what makes these projects hard. Change management is.

Stakeholder availability is the number one schedule risk in this class of project, and it is entirely predictable. Senior calendars fill eight weeks out. Booking placeholder time is free and it protects the critical path.

Most organizations replatforming a large site are carrying years of content they have already decided is worthless and have no mechanism to remove. Making the retirement decision before migration rather than during it is one of the few reliable ways to make a replatform meaningfully cheaper.

Without a freeze, content moves underneath the migration and the same page gets migrated twice. With a freeze and no exception process, somebody publishes to the old system anyway during a crisis. You need both.