SAP S/4HANA migration timeline: how long it really takes finance teams

The two-week conversion in the vendor demo is real. It is also the least interesting part of your migration, and if your plan is built around it, your budget is already wrong. Finance-led S/4HANA migrations take twelve to twenty-four months or more, and the reason has nothing to do with your IT team's speed. It is the finance workstream, the redesign of the chart of accounts, the migration of document data into the universal journal, and the user acceptance testing that has to survive a real period close, that decides the calendar. Here is the honest timeline, the milestones that actually matter, and the questions your CFO should be asking this quarter.

The demo timeline and the real one

SAP's demos are not lying; they are just measuring a different thing. The technical conversion, the SUM-based, brownfield, simple-landscape slice of the project, genuinely can take weeks, and the downtime window itself can be days or hours in a well-run conversion. But project duration and downtime are different numbers, and conflating them is where finance plans go wrong.

The full project includes the readiness check, the redesign of the chart of accounts, the migration of financial data, the UAT cycles, the parallel runs, and the first closes on the new system. That is the project the CFO approves, and it is the one that takes twelve to twenty-four months or more.

The market has caught on. In the SAPinsider S/4HANA Migration Benchmark Report 2025, based on 170 organizations, 55% cite project duration as a major concern, up from 37% in 2024, and 62% cite cost as the primary barrier. The report's own framing: the realization of extended migration timelines is becoming a more pressing challenge as the complexity of phased transitions, custom code refactoring, and business process reengineering increases. The market is telling you the demo timeline was always the exception, not the rule.

Why finance is the critical path

Why the data migration is the hard part

The deepest public source on this is Martin Schmidt, a product and topic expert at SAP, writing on SAP Community about finance data migration. His opening sentence should be printed in every project charter: finance data migration is probably the hardest part of any conversion to SAP S/4HANA. That sentence is not drama; it is the sequencing.

The mechanics explain why. The technical conversion, SUM, creates the universal journal table ACDOCA, and it creates it empty. Populating it, reconciling it to legacy totals, and re-validating it happens after the technical conversion, separately, per client, configured through IMG, and only after the preparation work: source checks, Maintenance Planner, Simplification Item check, custom code analysis, closing activities. Multiple dry runs are standard practice, not a sign of weakness. A dry run means loading real or representative data, running the reconciliation, finding the breaks, fixing the mappings, and doing it again until the numbers tie.

Finance data migration — the longest and riskiest workstream on the S/4HANA timeline

Reconciliation is a finance decision

The reconciliation reality deserves its own paragraph. Legacy FI documents live in BSEG and its satellites; the new world lives in ACDOCA, and the two do not line up row by row. The team has to agree, before the first dry run, what "reconciled" means: balances per company code, per account, per period, and who signs off when they tie. That agreement is a finance decision, not a technical one, and it is the first real test of whether the project has a finance owner or just a finance attendee.

Every dry run is a data-quality audit wearing a migration costume. The breaks it finds are rarely random: a balance that never tied because an account was used for something it was never designed for, a posting pattern that three generations of finance teams copied without ever documenting, a master record carrying a decade of legacy. Fixing the mapping is the easy half. The hard half is deciding who owns the correction in the source system, and what the corrected history means for the opening balances. Teams that treat dry runs as IT rehearsals rerun them until the plan slips. Teams that treat them as finance archaeology, with a named owner per break and a sign-off per correction, reach a tied reconciliation in two or three passes. That is why the dry-run count belongs in the plan as a range with an owner attached, not as a fixed number on a slide.

The design decisions that belong to finance

The chart of accounts redesign sits on top of that. S/4HANA drops the three-chart model per company code in favour of a unified chart of accounts, and that decision is a finance decision, not an IT one. It forces conversations about operating chart versus group chart versus country chart that most teams have never had explicitly, and it has to happen before the data migration, because the mapping defines the migration.

This is why the numbers look the way they do. In EMEA, finance teams are involved in 94% of S/4HANA decisions, the heaviest of any business function after IT. Finance is not a stakeholder in this project with a seat at the table; the finance workstream is the schedule, and everything else fits around it.

The honest calendar

A realistic calendar, for a mid-size company doing a brownfield or selective transition, looks like this:

• Readiness check and Simplification Item analysis: the first few weeks, before any commitment
• Custom code remediation: several months, overlapping everything else
• Finance data migration rehearsals: multiple dry runs, each one a full cycle
• Parallel runs: weeks of dual operation
• Finance UAT: cycles that have to cover a real period close, not a demo scenario
• Cutover: the technical event, and the smallest line on this list
• First close on the new system: the true go-live proof

The sequence matters as much as the items. The chart of accounts design has to finish before the data mapping, the mapping before the dry runs, the dry runs before UAT, and UAT before cutover. Finance phases do not compress well in parallel, because each one validates the previous one. That dependency chain is why the calendar runs in months, not weeks.

Finance UAT is where demo optimism goes to die, and that is the point. The test script has to cover a real period close: postings, clearing, foreign currency revaluation, accruals, cost allocation, the closing tasks, the report pack, the sign-off. Teams that run that script once discover the gaps; teams that run it three times fix them. A UAT that cannot run a full close is a demonstration wearing a test script.

Testing effort multiplies — successive dry runs, UAT cycles, and parallel runs before the first close

The rule of thumb I give every finance team: plan for at least two full period closes, month-end or quarter-end, on the new system before go-live. That single constraint pushes most mid-size projects past twelve months on its own, and it is the one constraint no demo timeline will ever show you, because it does not exist in the demo.

The budget nobody budgets

Cost and calendar move together, and the line item finance teams forget is the one that pays for the delay. ECC 6.0 mainstream maintenance ends December 31, 2027. Paid extended maintenance covers 2028 to 2030, and after 2030 only customer-specific maintenance remains. Every month the migration slips is a month of premium maintenance that was not in the original business case, and that line item is real money. It grows every month the project slips, and it is invisible on the vendor's timeline slide.

Greenfield deserves its own honesty. The argument "greenfield is faster because there is no legacy data to convert" sounds plausible and is usually wrong. Greenfield avoids the conversion baggage and replaces it with a full re-implementation: blueprint, configuration, data load, change management. In practice it usually runs longer than the conversion path, because nothing is inherited and everything has to be built.

And the big-bang weekend cutover, the one the project sponsor always proposes in the steering committee: feasible for small landscapes, and only small ones. With period-close, audit, and regulatory constraints, phased and selective transitions are the norm, and SAPinsider flags phased transitions as a key driver of the extended timelines. The weekend cutover is a fine answer to the wrong question.

There is also an audit angle that rarely makes the budget. BDO's guidance on migration timelines is blunt: delays increase audit, ICFR, and compliance risk, because the control environment you are running on is the one being retired, and the auditors know the dates. When a migration slips past the maintenance deadline, the IT problem becomes a financial reporting risk, and the CFO signs that risk.

The questions your CFO should ask

The single question that separates a real plan from a demo: where in the plan are two successful quarter-end closes after go-live? If the answer is nowhere, the timeline is a slide, not a plan, and the budget attached to it is a wish.

Then the follow-ups:

• How many dry runs of finance data migration are budgeted, and who has signed off the reconciliation to legacy totals?
• What does the unified chart of accounts design change for operating versus group reporting?
• What is the extended maintenance line item between the plan date and the go-live date?
• Which period closes does finance UAT have to survive before you trust the cutover?

A CFO who asks these questions changes the project, because each one forces a date and an owner onto the plan. A CFO who does not gets the demo timeline and the real bill, in that order.

The 2027 clock

The deadline is contractual, and it is closer than the industry acts. ECC 6.0 mainstream maintenance ends December 31, 2027. By February 2025, 32% of organizations had already migrated and 27% were in implementation, and per Basis Technologies' analysis of SAP and Gartner data, only 28% of the original roughly 35,000 ECC customers were live on S/4HANA at the end of 2023. The majority of the installed base still has to run the race, and the queue is the point: partners, auditors, and talent all prioritize the projects that are already running.

Extended maintenance exists, and treating it as a plan rather than an option is the CFO's risk to budget. The ecosystem moves on regardless: the auditors expect S/4HANA audit readiness, the AI innovations land on S/4HANA first, and the talent market prices ECC skills accordingly. Staying means paying a premium to stand still while the ecosystem moves on, and that premium compounds.

If you are reading this and the calendar already looks tight, the answer is scope, not panic. The selective transition exists precisely for this: take the finance-relevant scope first, protect the close cycle, and move the rest of the landscape in later waves. Phasing is the market's own answer to the 2027 date, and it beats a rushed big-bang that misses the close.

The people nobody adds to the plan

The calendar math hides a capacity problem. The finance team designing the unified chart of accounts, running the dry runs, and sitting in UAT is the same team closing the books every month. Nothing in the demo timeline accounts for that. The project plan shows finance workstream effort; the finance team's real calendar still shows the close, the audit, the budget cycle, and the tax filings. The honest plan has a capacity conversation in it: who backfills the close while the lead does the mapping, and what reporting gets deferred during UAT.

That conversation is usually the first one the CFO has to have, and it is the one that decides whether the timeline holds. Projects fail the calendar less often on technique than on the simple fact that the people who own the numbers were never given a second pair of hands.

The close

The moment that makes the whole calendar real is the first month-end close on the new system: the ledger reconciles to the legacy totals, the finance team finishes on time, and the sign-off takes an afternoon instead of a week. Projects built around finance get that outcome, because the schedule was built around period closes, dry runs, and the people who own the numbers. The demo timeline gets you to cutover. The finance timeline gets you to the close, and the close is the event the business actually cares about.

Your plan probably has a cutover date. Make it have a first-close date, two of them, and the budget that goes with them. You are on the honest calendar, and the honest calendar is the one that holds.

Sources

• Conversion to SAP S/4HANA: Insights into Finance Data Migration (Martin Schmidt, SAP Community)
• SAP S/4HANA Migration 2025 Benchmark Report (SAPinsider, Holland & Chawla Bhasin, February 2025, n=170)
• The True State of S/4HANA 2025 (Basis Technologies)
• SAP S/4HANA Migration Timelines and Audit Readiness (BDO)
• Move for Change: SAP ERP Maintenance Timelines (SAPinsider, on ECC 6.0 mainstream 2027, extended 2028-2030, customer-specific after 2030)