The 30-Day Transition Playbook: From Excel Sprawl to a Governed Go-Live

The claim, and what it rests on

Thirty days is not a marketing number. It is the compression of a ten-phase implementation methodology to the scope a mid-size company actually needs first.

EAConnect's implementation methodology defines a standard backbone of phases — mobilise, discover, data, platform, build, process, consumption, test, sign-off, cutover, hypercare — with scenario-specific additions for FP&A budgeting, workforce, capital and demand planning. Run in sequence with a partner for a multi-entity, multi-currency enterprise, that backbone is a quarter or more, and it should be. Run for one application — a single ledger, a chart of accounts, a budget and forecast, three source systems, a review workflow — the same phases compress into four weeks because most of their duration is waiting: for credentials, for decisions, for people to be available. The playbook below removes the waiting by ordering the work so that each week's inputs are ready before it starts.

Figure 1. The platform's phase backbone laid onto four weeks. Phases overlap because their dependencies allow it: the model is built while source credentials are being obtained; training runs while UAT is under way. Hypercare continues into month two.

What does not fit in thirty days

Multi-entity consolidation with intercompany eliminations. Multi-currency translation. Migration of a data warehouse. A planning process with more than one approval chain. Each of these is a second wave — typically another two to four weeks — and each should be scoped as one, not folded into the first go-live where it will be the thing that slips.

Before day one

The thirty days start when these are in hand. Most delayed implementations were delayed here, before the clock formally started.

Three files

A general-ledger export for at least the last full year and current year-to-date; the chart of accounts with its roll-up; the current budget and latest forecast, in whatever spreadsheet they live in. These are what week one runs on.

One sponsor, one owner

An executive sponsor who can settle a design decision in a day, and a finance owner — usually the FP&A lead — who will spend half their time on this for four weeks. Without the second, the first week's decisions become the fourth week's blockers.

A named ERP administrator

Whoever can create an integration record and issue credentials in the ERP, and has been told they will be asked to do so in week two. This is the single most common cause of a slipped week three.

The planners, identified

The ten or so people who will enter and review budgets, by name and department, and the fifteen who will read reports. They are the users for access setup in week two and the UAT participants in week four.

Week one: decide, audit, and prove it on files

Mobilise and discover — and, by the end of the second day, a working P&L, dashboard and planning grid built from the three files. The prototype is what turns the design conversation from abstract to specific.

Days 1–2 · Kickoff and first value

Kickoff sets the RACI and provisions a sandbox environment — an isolated stack with its own database namespace and storage, where configuration can be built and certified before anything touches production. The three files are loaded the same afternoon. The outcome, as described in the first article of this series, is a variance-analysed statement, a dashboard and an entry grid on the company's own numbers before the week's design sessions begin.

Days 2–4 · The design decisions

EAConnect's design-guidance questionnaire holds seventy-nine decisions, grouped by foundation, model fabric, system dimensions, data operations, governance and preferences. Each carries a suggested default and a rationale, so most are confirmations rather than debates. Nine are blocking — the build cannot proceed without an answer — and they are the agenda for the design sessions:

Decision	Why it blocks	Typical mid-market answer
Which planning scenario	Selects the blueprint; wrong scenario means wrong dimensions and processes	FP&A budget, with workforce as the second wave
Fiscal year start month	Drives the calendar and every time-based calculation	January or April; confirmed from the ledger
Is the source data row-oriented (one record per event)?	Determines whether a load is a fact table or a planning intersection	GL detail is row-oriented; the budget file is not
Do all measure groups share one dimension grain?	Decides one model or several publishing into one	Several: P&L, headcount and rates at their own grains
Who may activate each group of the spec	Ownership of the design document by section	FP&A lead for models; controller for the chart of accounts
Is the sample data full-grain or a partial export?	Prevents building on an unrepresentative extract	Full year, all entities, from the ledger
Period column format in the sample	Parsing rule for every time-stamped load	YYYY-MM, or fiscal period name
Stable, snake_case object codes	Codes are how promotion and reuse work; renames break both	Yes, and never rename via the spec
Preserve data before and after allocation or adjustment	Audit trail design; cannot be retrofitted	Yes: pre- and post- as separate data states

The remaining seventy decisions take defaults unless the finance owner objects. The chart-of-accounts audit — which accounts roll where, which are dormant, which map to which statement line — runs alongside and is usually the week's longest single task.

Day 5 · Install the blueprint

The Blueprint Gallery holds curated starting points — Opex, Headcount, Revenue, CapEx, Cash Flow Forecast, Balance Sheet Forecast — each bundling models, dimensions, hierarchies, forms and process patterns. Installing one into the sandbox is additive: it creates objects with the blueprint's codes and reuses environment-shared dimensions such as Entity and Calendar rather than duplicating them. The week ends with signed design decisions, an audited chart of accounts, and a blueprint installed against real data.

Week two: build the model, assisted

Platform and build — dimensions, hierarchies, calendar, models, drivers, entry forms, access. This is where the AI-assisted authoring changes the arithmetic of an implementation, and where the $10,000 baseline of services is mostly spent.

The spec is the build

Week one's decisions and the blueprint together produce a design document — in EAConnect, a structured spec with one row per object: each dimension, member set, hierarchy, model, measure, view, form, report and process, with its payload, its binding to existing objects and its apply status. The configuration agent reads that spec and applies it through the same services a builder would use by hand, addressing everything by business code so the result is idempotent and portable. What used to be two weeks of a consultant clicking through configuration screens becomes a review of a generated design followed by an apply, with the human effort going into the decisions rather than the keystrokes.

Figure 2. The spec-driven build. The generated design is reviewed by the people who will use it, on their own numbers, before it is approved at the wave gate. Services effort concentrates on the review and the decisions it surfaces.

Days 6–7

Structure

Dimensions and hierarchies from the audited chart of accounts; the fiscal calendar and its generated time dimension; scenarios and named versions; the entity and cost-centre structures.

Days 8–9

Models and forms

The P&L model at its grain; headcount and rates as separate models publishing into it; drivers as central variables; entry forms per department scoped by access rules; the statement views.

Day 10

Wave gate

The finance owner and two department heads enter one month of budget on the real forms and compare roll-ups to the ledger. Approve, or log the gaps and fix them on day eleven.

Week three: replace the files with live sources

Data and process — connections, flows, reconciliation, validation, schedules. The credentials requested in week one arrive; the model built in week two tells you exactly what every table is for.

A production process: NetSuite master data flow, then GL detail load into a planning table, with validation and gates available in the palette

Figure 3. The NetSuite actuals process as it exists at the end of week three: master-data flow, GL-detail load into the planning table, validation before the load is accepted. Built from the second article in this series.

Days	Task (from the methodology's data and process phases)	Output	What commonly slips
11	Source inventory and connectivity — one connection per system, credentials tested	Three working connections	Credentials not yet issued: the week-one ask was not actioned
11–13	Staging and first extract — master data (accounts, departments, entities, rates), then GL detail; flows run from the canvas while being built	Actuals in the planning table for the current year	A custom field the model needs that the extract does not include
13–14	Reconciliation rules and sign-off — loaded totals against the ledger's trial balance by entity and month; differences explained or fixed	Controller's sign-off on the actuals load	Post-close adjustments and a decision on how they are treated
14	Process dry-run and error handling — validation monitor before the load, alert branch on failure, retry policy for transient errors	Process certified in the sandbox	Nothing, usually; this is configuration
15	Production schedules — nightly for the ledger, on-demand for master data; historical backfill started overnight	The week-one statement now refreshes itself	API rate limits on multi-year history; plan for it to run over the weekend

Reconciliation is the step teams are tempted to skip and should not. A load that ties to the trial balance is what makes the platform's numbers the numbers; a load that nearly ties is a permanent argument.

Master-data ownership is settled in this week as well: who owns the chart of accounts, who may add a cost centre, and how changes reach the platform. With versioned hierarchies the answer is usually that the ERP remains the source and changes arrive through the master-data flow, with the planning owner reviewing new members before they are used.

Week four: govern, test, sign off, go live

Consumption, test, sign-off and cutover. The workflow that will run the budget cycle, the checks that prove the numbers, the four signatures, and the promotion from sandbox to production.

Days 16–17

The workflow app

Submit → review → approve → lock, with a validation gate on readiness before review. Slice locks close a version by entity and period once approved. Report broadcasts are scheduled — each subsidiary manager's statement to their inbox on day one of the month. The formatted board pack is built from a template.

Days 17–18

Calculation spot-check and training

A fixed suite of checks — twenty to thirty cells whose value can be computed by hand from the ledger — run against the platform. Training runs in parallel: planners on forms, reviewers on approvals, everyone on where the numbers come from.

Days 18–19

UAT and triage

The ten planners enter a real month; the reviewers approve it; the broadcast fires. Defects are triaged the same day and retested the next. UAT that runs with real users in their real scope, on data that ties to the ledger, rarely takes longer than two days.

Day 20

Four sign-offs and promotion

Design, data, security and go-live sign-offs, each a short document with a named signatory. Then promotion: the application's manifest — the complete closure of its objects — is exported from the sandbox and imported to production by code, structure only by default. The first production load runs that night.

Figure 4. Go-live is a promotion, not a rebuild. Structure moves by code; data arrives by schedule; credentials stay where they were entered.

After day thirty

Hypercare, the first close, and the second wave. The methodology's last phases are not compressed; they are the month after.

Hypercare, weeks 5–7

An issue backlog with an owner and a daily triage. Most items are data — a new account, a member nobody mapped — and most are closed by the master-data flow and a hierarchy review. Handoff to business-as-usual when a week passes with no critical item.

The first close

The parallel run of the methodology is, in this scope, the first month-end run on the platform alongside the old spreadsheet. If the two tie, the spreadsheet is retired the following month. If they do not, the reconciliation from week three tells you where to look.

The second wave

Workforce planning, the rolling forecast, a second entity, currency. Each is a blueprint, a spec, a sandbox and a promotion — the same four steps, in less than four weeks, because the platform, the team and the data are already there.

Who, how much, and what it costs

The four weeks are a commitment of people more than money. Here is the honest allocation for the stated scope.

Role	Week 1	Week 2	Week 3	Week 4	Total
Executive sponsor	4 h	2 h	1 h	3 h	10 h
Finance owner (FP&A lead)	20 h	16 h	12 h	20 h	68 h
Controller	8 h	4 h	10 h	4 h	26 h
ERP administrator	2 h	4 h	6 h	1 h	13 h
Department heads (×3)	3 h	4 h	—	6 h	13 h each
Planners (×10)	—	—	—	6 h	6 h each
EAConnect services (T&M)	~14 h	~24 h	~12 h	~20 h	~70 h

Services hours are concentrated in weeks two and four — the model review and the governance setup — and correspond to the typical baseline engagement in the low five figures on a time-and-materials basis. Week three is largely the customer's ERP administrator and controller with light support. Figures are practitioner estimates for the stated scope; multi-entity or multi-currency scope roughly doubles the services line.

What slips, and why

Credentials — the ERP integration record requested on day one and issued on day twelve. Ask on day one, in writing, with the date needed.
Chart-of-accounts decisions — dormant accounts nobody wants to close, mappings two people disagree on. The sponsor settles these in week one or they resurface in UAT.
UAT availability — ten planners for six hours in week four, booked in week one. Unbooked, it becomes week six.
Scope — "while we are at it, can we add the UK entity." The answer is yes, in wave two.

A practitioner's view for leaders

Opinions from people who have run planning implementations at both enterprise and mid-market scale. Not product claims.

Four weeks is a scope, not a speed

One application, one ledger, three sources, one approval chain. Hold that line and the date holds. Add an entity or a currency and you have started wave two early, at wave one's expense.

Prove it on files before anyone maps a field

The prototype on day two is not a demo; it is the thing every design decision is made against. Teams that start with integration argue about mappings for a model that does not exist.

The blocking decisions are the project

Nine questions, answered in week one by people who can answer them, remove most of the risk from weeks two to four. The other seventy take defaults. Spend the sponsor's time on the nine.

Reconcile to the trial balance, or do not go live

A platform whose actuals tie to the ledger becomes the source of truth in a month. One whose actuals nearly tie remains a second opinion forever.

Promote; never rebuild

Everything certified in the sandbox reaches production by manifest and code. The moment someone re-creates a form by hand in production, the two environments have diverged and the next change is a risk.

Book the people before the kickoff

Every slipped implementation we have seen slipped on a person's calendar, not on the technology. The ERP administrator's week-two hours and the planners' week-four hours are the critical path; book them on day one.