Most migration plans are a Gantt chart with a promise attached. The useful version is a list of artefacts: a thing that exists at the end of each week, that someone signed, that the next phase depends on. Activate gives you the list. Cloud ALM is where it lives. Neither of them will make a decision for you.
What follows is a 24-week conversion plan for a mid-sized ECC landscape — long enough to be real, short enough to be ambitious. Adjust the durations, keep the sequence and the gates.
Week 1, day 1: set up the system of record
Before any workshop, before any consultant is booked, the programme needs one place where status is true. Six things get configured in the first week, and they take about two days of real work:
Provision SAP Cloud ALM
Request the tenant, activate the service, connect the landscapes. Cloud ALM is included with your SAP support entitlement — it is not a purchase decision, it is a setup task that people postpone for months and then run the programme in Excel.
Create the project from the Activate roadmap
Pick the S/4HANA conversion roadmap for your edition. Cloud ALM generates the task list automatically, with descriptions and accelerators. That task list is your methodology — not a PDF.
Define timeboxes: 6 phases, 6 sprints, 4 milestones
Phases and sprints exist as objects in Cloud ALM, not as tabs in a spreadsheet. Sprint length: two weeks. Any other choice invites a debate you do not need.
Load the team with roles
Every task gets a role assignment. If a role has no name against it in week 1, it will be a gap in week 12.
Connect the quality gates
Four gates: scope (W2), design (W4), build complete (W22), go-live (W24). Each gate has an exit checklist and one owner with authority to say no.
Decide the reporting line
One weekly extract out of Cloud ALM: tasks late, requirements by status, test pass rate, open defects by severity. If the steering committee sees a different number from the project team, you have two programmes.
The rule for the rest of this page: every activity below produces an artefact that lives in Cloud ALM and has an owner. "We did the fit-to-standard workshop" is not an artefact. "47 requirements in the delta backlog, 12 rejected as standard, 35 approved by the process owner on 14 March" is.
Weeks 1–2 · Discover: what are we actually converting
Discover is short and it is where the business case gets tested against reality. Three tools do most of the work.
| Artefact | Produced with | Why it matters later |
|---|---|---|
| Readiness Check report | SAP Readiness Check 2.0 | Simplification items, custom code footprint, sizing input. It is the only honest estimate you will get before Explore. |
| Custom code inventory | Custom Code Migration app + ATC | Object count, usage evidence, remediation categories. Failure mode #2 starts here. |
| Scope statement | Cloud ALM scope + process hierarchy | Drives the automatic test scope later. Get the process list right once. |
| Landscape sketch | Solution architecture doc | Number of clients, DEV/QAS/PRD, interfaces, third parties. |
| Business case with a number | Finance + programme | Cost per month of delay. You will need it when a gate is contested. |
Gate 1 — end of week 2. Scope signed by the business owner, readiness report reviewed, custom code inventory complete enough to size. If the inventory is not complete, you do not have a scope, you have an intention.
Weeks 2–4 · Prepare: build the machine
- Landscape. DEV, QAS, PRD provisioned; a sandbox for ATC and code analysis; the conversion itself needs a separate copy for SUM rehearsals.
- ATC check variant agreed. This is a technical decision people defer for weeks: which S/4HANA checks run, at what priority, and who triages the findings. Agree it in Prepare or every developer invents their own answer.
- Team onboarding. Not a slide deck — a session where every person opens Cloud ALM and finds their tasks for sprint 1.
- Clean-core policy written. Five rules, a register, and a transport gate that can refuse. I expand on this in the Explore section because that is where it is applied.
- Integration inventory. Every interface, its owner, its direction, its protocol, and whether it survives S/4HANA unchanged. Interfaces are where conversions quietly overrun.
Gate 2 — end of week 4. Landscape live, ATC variant agreed, clean-core rules signed, integration inventory complete, sprint 1 backlog populated with user stories in Cloud ALM.
Weeks 4–10 · Explore: fit-to-standard, and the deltas you can defend
Explore is where the programme either adopts the standard or rebuilds its past. The mechanics come straight out of Activate: run fit-to-standard workshops against the preconfigured process content, capture every gap as a delta requirement, and decide what to do with each one.
Workshops by process area, not by module
Order-to-cash, procure-to-pay, record-to-report, and so on. Each workshop has a business owner who can say "we will change" and a decision log written during the session, not afterwards.
Every gap becomes a requirement with a disposition
In Cloud ALM: standard, configure, extend, side-by-side, or reject. A requirement with no disposition is not a requirement, it is a wish.
Clean core is a policy, applied per requirement
No modifications to standard objects. Extensions through released extension points. Released APIs only for integration. Side-by-side for anything heavy. Every deviation in a register with an owner and an expiry date.
Data model and volume
Which tables carry the volume, what archives, what stays. Decide archiving now — it changes the sizing, the duration of the migration, and sometimes the business case.
The Explore trap: a workshop that ends with "we'll see in the sprint" produces a delta that nobody sized. Every requirement that leaves a workshop without a disposition, an estimate and an owner is a surprise scheduled for Realize.
The clean core rules, in the form an architect can enforce
| Rule | Enforced how | If someone asks for an exception |
|---|---|---|
| No modification of standard objects | Transport gate + code review | Redesign the requirement. There is no exception path. |
| Extensions via released extension points | Named, versioned, owned | RAP or side-by-side, decided in Explore |
| Released APIs only | Interface register | Owner, version, deprecation date or it does not ship |
| Heavy logic stays out of the core | Architecture review | BTP / side-by-side service with its own lifecycle |
| Every deviation is registered | Register with expiry | Deviations with dates get fixed; the others become the next migration |
Custom code: the triage that actually survives
This is where 60 % of the effort hides in 2 % of the objects. Run it in this order, in weeks 5–10:
- Inventory. Every custom object with type, size, last change, author, transporting system.
- Usage evidence. ABAP Call Monitor / SQL trace / transport history over 12 months. An object nobody executed in a year is a retirement candidate, not a migration item.
- ATC with the S/4HANA check variant. Technical blockers only — it does not tell you what the code does, which is why step 2 comes first.
- Four buckets: retire, replace by standard, adapt, rewrite (RAP or side-by-side).
- Size in developer-days, not object counts. "1 200 objects" means nothing to a steering committee; "180 objects, 340 days, 14 weeks at four developers" does.
Expect roughly: 30–50 % retirement candidates, 20–30 % mapped to standard, only 20–30 % genuinely rewritten. Programmes that skip the usage analysis assume 100 % must migrate — and then staff for it. This is also the one place where an agent helps: classification and evidence gathering at scale, with a human approving every remedy. See the agent playbooks.
Weeks 10–22 · Realize: six sprints, and the things that run in parallel
| Sprint | Configuration | Code | Data & test |
|---|---|---|---|
| S1 · W10–12 | Core finance + master data | Retirement list executed (objects deleted, not migrated) | Golden records defined |
| S2 · W12–14 | Logistics core | Adaptations, first RAP extensions | Data migration cycle 1 (DEV) |
| S3 · W14–16 | Remaining scope + integrations | Interfaces rebuilt on released APIs | Unit + integration tests wired |
| S4 · W16–18 | Roles, authorisations, output | Performance fixes from ATC | Data cycle 2, reconciliation rules signed |
| S5 · W18–20 | Cutover tooling, archiving | Regression fixes | Full regression pack green |
| S6 · W20–22 | Freeze + defect burn-down | Only defects, no scope | Data cycle 3 at production volume |
Testing, as Cloud ALM does it
The important property of Cloud ALM test management is traceability: the test scope is derived from the project scope, test cases come from business process content, and they can be assigned to requirements and user stories. That means a requirement with no test is visible as a gap instead of being discovered during UAT.
Test plan per sprint, plus one end-to-end plan for deploy
Both live in Cloud ALM. The sprint plan proves the increment; the end-to-end plan proves the business.
Manual where judgement is required, automated where it is not
Golden records, interface smoke tests and regression packs are automated through your automation provider, orchestrated from Cloud ALM.
Defects triaged daily, with a P1 definition agreed before go-live
If everything is P1, nothing is. Write the definition in Prepare, not during hypercare.
Business availability is the constraint nobody plans. The same fifteen key users are asked to test, train, sign off and keep running the business. Book their time in Prepare, in their calendars, with their manager's agreement — or watch sprint 5 slip because nobody could attend UAT.
Weeks 22–24 · Deploy: rehearse, then do it once
Cutover runbook: every step has an owner, a duration and a verification
"Load master data — 45 min — check record counts and a sample of 20" beats "load master data".
Two timed rehearsals
One at production data volume, one with the actual people who will be awake at 2 a.m. The second one is the useful one.
A rollback point after each major stage, with a decision time
The question "do we roll back?" must be asked at 04:00 by a named person, not discovered at 09:00.
Go/no-go with an explicit checklist
Open P1 defects = 0, data reconciliation signed, business readiness confirmed, hypercare staffed. Each line is a yes or a no, not a colour.
Hypercare rota published before go-live
Named people, shifts, escalation path, and a triage rule. Anyone who has run a go-live knows the first 72 hours decide the perception of the whole project.
Gate 4 — go-live. Two rehearsals executed within the window, data reconciliation signed by finance, zero open P1, hypercare rota published.
Week 24+ · Run: what Cloud ALM is for after go-live
Cloud ALM does not stop being useful at go-live; that is when its operations apps start earning. Four things to switch on in hypercare week:
- Business Process Monitoring — are the processes actually completing, end to end, with the volume you expect? This catches the integration that silently stops at 03:00.
- Integration & API Monitoring — every interface, its error rate, its latency. The single most valuable screen in the first month.
- Health Monitoring — system availability, job failures, exceptions.
- Regression testing for the next update — the same test cases, re-run on the new release. This is what turns upgrades from events into routine.
Twelve mistakes, and what each one costs
| # | Mistake | What you see | What it costs |
|---|---|---|---|
| 1 | No written definition of done | Everything is green, then it isn't | Weeks, discovered late |
| 2 | Custom code inventoried only "in scope" | New objects appear in sprint 4 | Re-planning, 4–8 weeks |
| 3 | Clean core as a slogan | Every exception approved by exhaustion | The same debt, version 2 |
| 4 | Delta requirements without disposition | "We'll see in the sprint" | Unplanned scope, unbudgeted |
| 5 | Data quality deferred to the mapping script | A developer making business decisions at midnight | Wrong data in production, forever |
| 6 | No reconciliation keys agreed in writing | "Finance will check it" | Go-live blocked at the last gate |
| 7 | Test scope built from scratch instead of from the process model | Hundreds of tests, no traceability | Full regression takes weeks |
| 8 | Business availability assumed infinite | Workshops with 3 of 15 attendees | Sprint slippage nobody owns |
| 9 | One rehearsal, cancelled | The plan had no slack | The first dry run is the last chance |
| 10 | Archiving decided after sizing | Migration window too short | Extra hardware or a longer outage |
| 11 | Interfaces without an owner | The third-party system "just breaks" | Hypercare firefighting |
| 12 | Two sources of truth (Excel + Cloud ALM) | Two status reports, two truths | Trust, then budget |
What to report every week
One page, from Cloud ALM, not from anyone's memory: