SAP S/4HANA installation

• Greenfield (new install): a fresh S/4HANA system, configured from scratch, ideal for a clean start.
• Brownfield (system conversion): converting an existing ECC system in place to S/4HANA, preserving data and much configuration.
• Selective / bluefield: a hybrid that migrates chosen data into a new system.

There is a third path worth naming because it appears in real projects: a selective data transition, which takes some history and configuration from the existing system into a new one. It is neither greenfield nor brownfield, it needs specialist tooling, and it exists because the choice between keeping everything and keeping nothing is often the wrong question.

You install HANA, then use SWPM/Maintenance Planner to install the S/4HANA application on top, then set up the Fiori front-end (embedded or standalone). Business configuration follows, increasingly via SAP’s guided configuration tooling.

Installation has a small set of tools and knowing which does what removes most of the confusion.

Maintenance Planner is where a conversion or an update starts. It runs against the system's data in the support backbone, checks that the target version is possible, verifies that add-ons and business functions are supported, and produces the stack configuration file that everything else consumes. A conversion that cannot get past Maintenance Planner is telling you something before any downtime is booked.

Software Provisioning Manager installs, copies and renames systems. It is the tool for a new installation and for system copies.

Software Update Manager performs the update or the conversion itself, and it is the one that runs during the downtime window. Its phases, and where a run can be resumed after a failure, are worth knowing before rather than during.

The readiness check runs against the existing system and reports simplification items, custom code findings and sizing. It is analysis rather than execution, and it is what tells you how large the project is.

Underneath, the host agent and the maintenance certificate are the two things that quietly block progress when missing.

A conversion adds mandatory steps: the Maintenance Planner and Simplification Item Check assess readiness, Customer-Vendor Integration prepares Business Partner, custom code is checked for S/4HANA compatibility, and Software Update Manager (SUM) with DMO performs the database migration and conversion together.

The pre-conversion work is where the effort actually is, and it happens weeks before anything is installed. Simplification items must be checked and resolved. Custom code must be analysed and remediated. Customer and vendor masters must be prepared for Business Partner conversion, which is frequently the longest single item. Open items in components being replaced have to be cleared. None of that is a technical activity, and skipping it produces a conversion that fails in the middle rather than one that succeeds.

Confirm HANA and S/4HANA start, Fiori launchpad works, and core processes function. For conversions, validate data and custom code thoroughly in a sandbox conversion before touching production.

A fuller list is worth having before declaring the system usable. Check that the database and instances start and stop cleanly, that a user can log in through both SAP GUI and the Fiori launchpad, that a representative transaction posts end to end in each core process, that background jobs are scheduled, that transports import, that interfaces connect, and that a backup runs and can be restored. The last one is the one most often assumed rather than tested.

• Greenfield or brownfield. A new implementation gives clean processes and a full data migration. A conversion keeps history and configuration, including the parts nobody wanted. The honest question is how much of the existing system is worth keeping.
• Where it runs. On-premise, private cloud or public cloud, and that decision constrains everything else. See the release notes for what changes with each version.
• Sizing. Memory for HANA, sized from a report against the real system rather than estimated.
• How many rehearsals. A conversion is executed several times in non-production before the real one, with timings, and that is what makes the downtime window predictable.

An installation produces one system. A project needs a landscape, and the sequence is worth knowing.

Development first. It is where configuration is made and transports originate, so everything else depends on it existing.

Quality assurance next, and it should be a copy of production rather than of development, because testing against unrealistic data proves little. That means a system copy from production is part of the routine rather than a one-off, and it has to be repeatable.

Production last, with the transport route configured so changes flow one way.

Beyond the three, most landscapes need a sandbox for trying things that must never reach the transport path, and a training system refreshed before each course.

Client strategy sits inside this. Within development there is typically a customising client where configuration is made and a unit test client for trying it with data. Which clients allow changes, and which are locked, is set per client and it is the control that stops configuration being made where it cannot be transported.

System refreshes are the recurring operational job: copying production down to quality assurance, then scrambling or removing sensitive data, then reconnecting interfaces to test endpoints. That last step is the one that goes wrong, and a refreshed system still pointing at a production partner is a memorable incident.

The technical conversion runs while the business cannot use the system, so the length of that window is often the constraint the whole project is planned around.

The update tool splits its work into uptime and downtime phases. Uptime processing prepares as much as possible while users are still working: shadow structures are built alongside the live system. Downtime is what genuinely cannot be done with users on.

Near zero downtime techniques go further, at the cost of complexity and licensing, and they are worth it for systems where a weekend is not available.

What actually determines the window in practice is less the tool and more the data. Large tables take longer to convert, and the finance data model change in particular is proportional to volume. That is why archiving before a conversion is one of the highest-value preparation activities: every document archived is one not converted.

Rehearsals produce the number. The first run gives an estimate, the second gives a plan, and the timings from them are what the business commits to. A window quoted from experience elsewhere rather than from a rehearsal on this system is a guess.

• Choosing greenfield vs brownfield without analysis.
• Skipping the Simplification Item / custom-code checks in a conversion.
• Not doing a sandbox conversion first.

• Starting the technical conversion before the functional preparation. The tools will stop you, later and more expensively than the readiness check would have.
• One rehearsal. The first run always finds something, so the second is the one that produces a reliable plan.
• No tested rollback. See the HANA install and the Fiori install for the neighbouring components.

Running the installer is the mechanical half, and planning a conversion around what the readiness check found is the part you do in the course.

The number the business actually needs is the downtime window, and the only honest source for it is a rehearsal on this system with this data. Everything else is an estimate borrowed from a different landscape.