ERP Method Command Centre

Keystone is built across four assets, all openly available:

• The methodology itself — six phases, twenty stages, the gate scheme (two real Board Gates plus an Executive Sponsor's cutover Go/No-Go), governance bodies and cadences, role catalogue with role distinctions named, an eight-level testing model with explicit role distinctions per level, and adoption treated as a governed workstream rather than a soft-skills add-on.
• The methodology pages at /method/* — written method covering Lifecycle, Gates & Business Case, Testing, Roles & Governance, Adoption, and Pre-drafted Artefacts. Read end-to-end or as reference.
• This Command Centre — interactive reference and diagnostic tool. Walk the methodology tab by tab. Tick exit criteria per stage in the browser, with state saved locally so your readiness assessments persist between visits.
• Supporting Documents at /downloads.html — downloadable artefact templates (Word, Excel, PowerPoint), seven slide decks for the methodology end-to-end, decision frameworks and worked examples. Free to use, adapt, fork.

The Story page explains why each piece exists.

Keystone is openly published. Anyone may use, adapt, or teach it. There is no licence, no signup, no gate, no paywall. Templates are downloadable in editable formats. The methodology is free.

Three reasons it's free:

• The patterns shouldn't be locked behind a day rate. The methodology distils what works across thirty-plus programmes — that has more value to the wider community than to one consultant's billing model.
• The asset traded on is judgement, not method. The methodology is how the judgement gets demonstrated before any money is spent. A buyer can read the method openly, decide whether the framework fits, and only then ask whether judgement layered on top is worth paying for.
• It improves through use. Templates and methodology evolve as practitioners apply them and feed back. Locked methodology stagnates; openly-published methodology iterates.

Andy Peel, who built the methodology, sells time on programmes that benefit from someone who's seen this shape of problem before. The methodology is the proof of judgement; the time is the asset.

The Command Centre uses a small set of consistent interaction patterns. Once you've spotted them once, the whole site reads the same way:

• Hover any underlined term for an inline explanation. Look for the dotted underline (e.g. "business rules", "smoke test", "vendor submissions") — hover for a definition, often with worked examples.
• Click any tile marked "click to expand" for the detailed content. Default-closed collapsible tiles appear on the Data tab, Vendor & Platform tab, RACI phase grouping, and Roles by Phase. They keep the page scannable; the detail is one click away.
• Click any stage card on the Stages tab for the full stage detail — activities, deliverables, owners, audience, common mistakes. The detail panel appears below the stage's phase. Click again or close the × to dismiss.
• Toggle "By Phase / By Role" on the Roles by Phase and RACI tabs to switch between two cuts of the same data — phase-first or role-first.
• Tick exit-criteria items on the Exit Criteria tab. Browser stores your readiness state locally — assessments persist between visits on the same device, but don't follow you to other devices unless you export.
• Cross-links to / from the methodology pages let you move between the written method and the interactive surface without losing your place.

If you're new to the site: open /method/index.html for the written overview, walk back here to drill into specifics, and download what's useful from /downloads.html as you go.

Keystone is a generic ERP delivery methodology. It has been refined across thirty-plus programmes — the deepest of those on Microsoft Dynamics 365 (F&O, SCM, CE) — and where the methodology gives concrete examples, vocabulary or vendor specifics, those typically lean D365.

The structure itself — six phases, twenty stages, the gate scheme, role distinctions, the eight-level testing model, RACI — adapts to any ERP platform: SAP S/4HANA, Oracle Cloud ERP, Workday, NetSuite or other. The phases sequence the same way, the gates do the same job, the role distinctions hold, the testing model applies.

Where the Command Centre includes platform-specific content — cost ranges, service tiers, functional summaries on the Vendor & Platform tab — it is included primarily for reference. Real cost figures, qualifying criteria and functional positioning shift continuously and should be confirmed with your SI or directly with the vendor before any commitment in a Full Business Case, an SOW, or a board paper.

Honest positioning matters more than vendor-neutral pretence. The methodology speaks D365 most fluently because the practitioner who built it has run more D365 programmes than any other platform. The structure translates; the examples lean.

A single Business Architect can credibly carry one functional area; they cannot credibly carry six. A single SI Functional Lead can hold one workstream end-to-end on a small programme; they cannot hold every named sub-process within Finance (AP, AR, Assets, GL, Treasury, Tax) on a 1,500-user programme. Sizing isn't just headcount — it's who can hold a process / module / sub-process domain credibly under load.

When more than one of a role exists, name a Lead. Multiple Business Architects → Lead BA carries cross-domain Accountable duties on RACI; individual BAs are Accountable for domain-specific decisions. Same pattern: Lead Functional Consultant within a workstream Functional Lead's team; Lead SA where multiple module SAs sit; Lead Project Manager on the largest programmes where several PMs need coordination beyond what the Programme Manager carries directly.

Common mistake: SI bids on small-programme sizing with a "one Functional Consultant per workstream" model when the programme is actually medium-to-large. The named consultant becomes the bottleneck mid-build, change requests pile up to add specialists, and the Full Business Case at S12 no longer holds. Sizing the team honestly at Programme Setup & Mobilisation (S10) — and naming Leads where roles multiply — is part of the mobilisation deliverable, not a discovery later.

Master Data = the relatively static reference records: customers, suppliers, products, employees, chart of accounts, cost centres. This is what Data Hygiene works on from Value Definition & Case for Change (S2) onwards — cleansing, deduplication, hierarchy fixes, reference-data rationalisation. Target-agnostic: a duplicate customer is a duplicate customer regardless of which ERP wins, which is why the work can start before Selection completes.

Transactional Data = the operational records flowing through the business: sales orders, invoices, GL postings, stock movements, journal entries, payments. Migrated late in the cutover sequence and usually only the open / unfinished records at cutover — the rest archived or aggregated as opening balances. The cutover sequence itself runs master first, then transactional, then reconciliation.

Many Client-side stakeholders think "data migration" is one bucket. It isn't — the two halves have different owners, different timelines, different cleansing demands.

Extract → Transform → Load.

• Extract: pull data from source systems — legacy ERP, spreadsheets, departmental databases, third-party tools.
• Transform: apply mapping rules (legacy field → target field), cleansing rules, defaulting rules for fields the legacy system doesn't carry, currency / unit / hierarchy conversions. This is where most defects live. Every transform rule needs to be documented, tested, signed off — that's what the migration mapping spec is.
• Load: insert into the target system through its proper APIs, validate against the target's business rules, reconcile counts and totals against the source.

Two clean dry runs at full volume, with reconciliation reports, are non-negotiable. The second dry run at full volume in Testing (S14) is where most defects surface — skipping it pushes them into go-live.

ETL activity is layered, not single-shot. There isn't one moment when "the ETL starts." Six distinct kinds of run across the lifecycle, each teaching you something different about where the data is breaking.

• Programme Setup & Mobilisation (S10): target environments live (per NFT). Pipeline can technically run but no source profile and no mapping — nothing meaningful to migrate yet.
• Discovery (S11): profiling ETLs — Extract only. Source data pulled out for the source data quality scorecard. No Transform, no Load against the target.
• End Solution Design & Full Business Case (S12) / start Build & Configuration (S13): first end-to-end pipeline smoke test — small-scale Master Data only, against a sandbox target, once draft mapping has signed off in the SDD ↓ docx. Not a formal Dry Run; the first time the pipeline runs end-to-end to find obvious breakage.
• Build & Configuration (S13): Dry Run 1 (formal) — Master Data at meaningful scale. Reconciliation begins.
• Testing (S14): Dry Run 2 — full volume, with Transactional Data layered on top of clean Master Data. The reconciliation report is the gate item.
• Cutover Planning (S15): dress rehearsal — last opportunity to catch defects before Go-Live.
• Deployment & Go-Live (S16): cutover ETL — production.

Master first, Transactional layered on. Smoke tests, Dry Run 1 and the first half of Dry Run 2 migrate Master Data only. Once Master Data lands cleanly into the target's reference tables, Transactional Data ETLs are layered on top — sales orders against valid customer/product references, GL postings against the chart of accounts. Master is the smaller and more stable population (test the pipeline first); Transactional integrity depends on Master being correct in the target.

Typically 4 to 6 ETL iterations across S13 into S14 as defects surface, get fixed, and the next run reveals the next layer. Where the ETL pipeline is automated, runs can continue iteratively until no errors surface — modern migration tooling supports this. Manual ETL processes constrain the iteration count and reliably leave defects in flight at cutover.

Completion deadlines. Data Hygiene must be substantially complete by the start of Discovery (S11) — SI profiling depends on cleansed master data, not work-in-progress. Migration completes at cutover (S16) with post-go-live validation in Hypercare & Stabilisation (S17).

Errors during ETL split into four types with different ownership. Lock this split into the SOW at Programme Setup & Mobilisation (S10).

• Data quality errors (duplicates, broken references, missing mandatory values, source-system inconsistencies) — owned by Data Owners (Client), driven by the Data Lead. The cleansing accountability sits in the business; the SI doesn't have the domain knowledge to do it well.
• Mapping errors (legacy field mapped to wrong target field) — owned by the SI Data Migration Lead. They own the mapping spec; corrections are theirs.
• Transform-logic errors (wrong defaulting rule, broken cleansing logic) — SI Data Migration Lead with Data Lead sign-off. SI codes the rule; Data Lead validates the business intent.
• Performance errors (ETL too slow for the cutover window) — owned by the SI Technical Lead. Infrastructure and tuning are theirs.

Warning: do not let the SI fix data quality issues. The Data Lead drives Data Owners to fix data hygiene defects in the source system, then re-runs the ETL. SI billing day rates to clean Client master data is one of the most reliably expensive sub-patterns in data migration — and it leaves the Client carrying dirty data into BAU because the SI fixed the symptom, not the cause.

SIs implementing a given platform (D365 F&O, D365 CE, SAP S/4HANA, Workday) have done data migration dozens of times. They have proven templates: object catalogues per module, mapping templates per master-data domain, reconciliation templates, dry-run runbooks, defect-classification taxonomies. Ask for them on day one of Programme Setup & Mobilisation (S10). Don't start blank.

The Keystone artefact library carries worked examples — the Customers Data Migration Mapping (Excel) and Customers Data Migration Specification (Word) on the Supporting Documents page — as a structured starting point the Client walks into the first SI workshop with.

Warning: SIs that won't share their templates are a warning signal — either they don't have them (concerning), or they want to bill for redoing the same thinking (also concerning). The Client owns the methodology; the SI brings proven accelerators that fit it.

Single switch. Every integration goes live on Day 1. All finance and SCM interfaces — ledger postings, supplier invoicing, customer billing, stock movements, banking, tax — are cut over together at the same cutover event.

Suits: simpler estates; single-platform replacements; programmes with an urgent or regulatory-driven business case; organisations where keeping two systems in parallel is operationally untenable.

Plus: shortest legacy retirement (no parallel running); cleanest commercial position with the SI (firm pricing for one cutover); single set of dry runs; benefits land fastest.

Warning: highest single-event risk. Every integration must be tested and ready simultaneously. Defects cascade across multiple interfaces at once. The Cutover Go/No-Go (S15) is binary across the entire estate — one weak link can stop the whole switch.

Multiple cutover events. Brands, entities, regions or factories migrate over time. Temporary integrations bridge the legacy systems and the new platform during the transition, keeping both in sync as each unit comes online. Permanent integrations are built once for the new estate and replace the temporary ones as legacy retires.

Suits: multi-brand, multi-entity, multi-region or multi-factory rollouts; estates that cannot all migrate simultaneously due to scale, risk appetite or operational windows; programmes where benefits per wave justify the parallel cost.

Plus: lower per-event risk (one wave at a time); learnings from each wave reduce defects in the next; commercial framework supports per-wave re-baselining; reversibility per wave is realistic.

Relationship to multi-wave delivery. Phased integration is about how interfaces are sequenced; multi-wave is about how the programme delivers. They typically coexist — a multi-wave programme nearly always uses temporary integrations bridging legacy and new while waves migrate, with permanent integrations retiring the bridges as legacy winds down. Big Bang is incompatible with multi-wave; Greenfield is only compatible if each wave is genuinely greenfield.

Warning: the most expensive trap is letting temporary integrations become permanent because nobody owns retirement. Lock the temp-integration retirement plan in the Solution Design at S12 — named owner, target retirement date per integration, named successor permanent integration. Carrying two systems and the bridges between them for years is one of the most reliably under-estimated costs in multi-wave programmes.

No legacy integrations to retire, no historical data to migrate beyond opening balances. Suits a new business unit standing up, an M&A integration onto the parent's platform, a brand-new operation, or a divestment establishing standalone systems.

Plus: the cleanest possible cutover — no parallel running, no temp integrations, no legacy data quality issues to inherit. Highest control over data quality from day one. Fastest realisation of benefits because there is no compromise required for backward compatibility.

Suits: standing up a new entity; carve-outs from M&A; new geographies or factories with no inherited systems; replacing a discrete legacy that has no upstream dependencies.

Warning: Greenfield can be a smokescreen for not addressing the legacy estate — standing up new clean while the legacy mess persists alongside, deferred indefinitely. Be honest in the business case about what gets retired vs. what stays running. Otherwise the “greenfield” programme delivers benefits on paper while operations carry both estates.