SAP · S/4HANA & RISE
The move to S/4HANA is a decision about the whole estate, made once.
Noble plans and delivers S/4HANA programmes end to end: the choice between a new implementation and a conversion, the deployment model, the migration of the data that will be trusted afterwards, the testing that proves the business still runs, the cutover, and the operational hypercare that follows. The work is organised around the estate the system sits in — integration, data, identity and operations — because that is what actually moves.
What is being decided
Every S/4HANA programme is three decisions before it is a project. The first is the transition path: a new implementation, which starts from a clean configuration and treats the existing system as a source of data and lessons; a system conversion, which carries the existing system, its customisation and its history into S/4HANA in place; or a selective transition, which takes some of each. The second is the deployment model — on-premise, hosted private cloud, or one of the RISE with SAP arrangements in which SAP operates the platform — and it is a decision about who runs what, not about where a server sits. The third is scope: which entities, which processes and which countries move first, and what stays on the old system while they do.
Noble’s role is to make those decisions with the organisation on evidence — the state of the current system, the volume and quality of its data, the interfaces that depend on it, and the operating model that will run the result — and then to deliver the programme that follows from them. The decisions are recorded with their reasons, so that when the programme is a year old the people running it know why it is shaped the way it is.
Three paths, one target
The transition paths differ in what they carry across. All three end in the same place, and all three are sized by the same four things: the data, the interfaces, the custom code and the people who will operate the result.
- 01New implementationClean configuration; the old system becomes a data source
- 02System conversionThe existing system carried across in place, with its history
- 03Selective transitionChosen processes, entities and history; the rest rebuilt
The gate before the target is the cutover: whichever path is taken, the business crosses it once, on a rehearsed plan, with a rollback that has been tested.
What the service covers
Six areas, in roughly the order a programme moves through them. Each is a body of work in its own right; together they are the programme.
Assessment and the transition decision
A reading of the current system before anything is promised: the custom code and what still uses it, the data volumes and their quality, the interfaces and who owns the other end of each, and the processes the organisation runs that its system does not know about. The transition path and the deployment model are chosen from that reading, and the reasons are written down.
- Custom-code analysis and simplification-item review
- Data volume, quality and archiving assessment
- Interface inventory, with an owner for each end
- Deployment-model comparison: on-premise, hosted and RISE with SAP
- Scope, sequencing and the case for each wave
New implementation and conversion
The build itself, on whichever path was chosen. A new implementation is configured against how the organisation works, with the standard preferred and every departure from it justified. A conversion is executed as a controlled sequence — preparation, technical conversion, functional adjustment — with the existing customisation retired where the standard now covers it and carried only where it still earns its place.
- Fit-to-standard workshops and the configuration that follows them
- Conversion preparation, execution and functional adjustment
- Retirement or re-implementation of custom developments
- Multi-entity and multi-country rollout on a template
- Landscape consolidation where several systems become one
Data migration and reconciliation
The part that decides whether anyone trusts the new system. Master and transactional data are profiled, cleansed and mapped before they move; the load is rehearsed until it is boring; and every migrated figure is reconciled to its source, with the differences explained rather than absorbed. Historical data is migrated, archived or left behind by decision, not by accident.
- Data profiling, cleansing rules and ownership
- Migration design, mapping and transformation logic
- Mock loads, rehearsed to a repeatable runbook
- Reconciliation to the source of record, with differences explained
- Archiving and retention decisions for historical data
Testing and regression
Testing is planned from the business process, not from the configuration screen: unit tests on what was built, integration tests across the interfaces, and user acceptance run by the people who will do the work, on scenarios written from how they actually do it today. Regression coverage is kept after go-live, so that upgrades and releases are tested against the same scenarios rather than against memory.
- Test strategy tied to business processes and interfaces
- Integration and end-to-end testing across the estate
- User acceptance on scenarios written by the business
- Regression suites kept alive for upgrades and releases
- Performance and volume testing before cutover
Cutover and hypercare
The cutover is planned to the hour and rehearsed at least once in full, with a go/no-go that has real criteria and a rollback that has actually been executed in a rehearsal. Hypercare afterwards is staffed by the people who built the system, with a defined end: the period closes when the agreed operational criteria are met, and the system is handed to whoever runs it next — Noble’s managed service or the organisation’s own team.
- Cutover plan, rehearsal and go/no-go criteria
- Rollback that has been executed, not only written
- Hypercare with defined exit criteria
- Handover to managed operations or the in-house team
Upgrades, releases and the years after
An S/4HANA system is upgraded on a cadence for the rest of its life, and each upgrade is a small programme: impact analysis on the custom code and the interfaces, regression against the kept scenarios, and a release window agreed with the business. Noble plans and runs those, and keeps the system inside SAP’s maintenance windows so that an upgrade never becomes an emergency.
- Release and upgrade planning against SAP’s maintenance calendar
- Impact analysis on custom code and interfaces
- Regression against the scenarios kept from the programme
- Feature adoption where a release changes what the standard covers
The programme, in sequence
The stages a programme passes through, and the two gates it must pass: the migrated data reconciled, and the cutover rehearsed. Neither is a formality, and neither is skipped to hold a date.
- 01AssessCode, data, interfaces, operating model
- 02DesignPath, deployment model, scope
- 03Build or convertConfiguration, conversion, custom code
- 04Migrate dataReconciled to source
- 05TestIntegration, acceptance, regression
- 06Cut overRehearsed, with rollback
- 07Hypercare and runDefined exit, then managed service
Where this connects
A transformation is the moment every other SAP subject arrives at once. These are the pages that carry the rest of it.
- BTP, Integration & ExtensionsEvery interface the old system had needs a home on the new one, and the customisation that survives is rebuilt side-by-side so the core stays upgradeable.
- Data, Analytics & PlanningThe reporting layer has to reconcile with the new system from its first period-end; migration and analytics are planned together.
- Managed SAP ServicesWhere a programme goes when hypercare ends: the same people, on a steady operating rhythm.
The services alongside
- Digital TransformationEnterprise architecture and process transformation — the decisions an ERP programme forces about how the organisation works, and the broader ERP work that is not SAP.
- CloudThe platform under a hosted or private-cloud deployment, its landing zone, and the resilience the system inherits from it.
- SecurityAuthorisations and identity alignment are designed into the programme, not added after the first audit.
SAP, S/4HANA, RISE with SAP and SAP S/4HANA Cloud are products and offerings of SAP SE, named here to identify what the work is done on. All marks belong to their owners. Broader ERP and enterprise-application work that is not SAP is described under Digital Transformation.
Start with the system you have.
Describe the current system, what depends on it and what the organisation needs the next one to do. The transition decision follows from that, and it is the first thing to settle.