How SAP projects are structured

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 9 October 2026

SAP project structure is three things at once: an approach — greenfield, brownfield or selective data transition — that decides what is kept from the old system; a run of SAP implementation phases from preparation to go-live; and a team organised in streams. Every staffing call assumes you can tell which shape a seat sits in.

What are the SAP implementation phases?

Most programmes today follow SAP Activate, whose phases take a project from discovery and preparation through design and build to deployment and operations. In plain terms, the project is scoped and staffed, the design is agreed in workshops against the standard system, the build and the test cycles happen, the business is moved across in a cutover, and the live system is handed to support. Older programmes and older CVs use the ASAP names for the same arc, with a business blueprint where Activate has its explore phase. The phases themselves, with their deliverables and quality gates, are covered in SAP Activate explained, and the weekend that ends the deploy phase in SAP cutover and hypercare explained. What this page adds is the layer above the method: what kind of project the phases are being run for.

Greenfield, brownfield or selective data transition: what is the difference?

The difference is how much of the old system survives the move. A greenfield project builds a new system and carries over only data; a brownfield project, which SAP calls a system conversion, transforms the existing system in place; a selective data transition sits between them, and some tool vendors and consultancies call it bluefield. The choice is made in the discover and prepare phases, and it reshapes everything after it — the workshops, the test volume, the custom code effort and the cutover.

Each approach staffs differently. A greenfield build is heavy on functional consultants and design, and is the dominant shape in markets still building their first systems, such as the Gulf. A conversion is analysis-heavy — simplification items, custom code checks, finance data reconciliation — and gives developers and Basis unusual weight. A selective transition needs a specialist migration team and an architect who can say exactly which slice moves.

What is an SAP rollout project?

A rollout lands a template that is already live somewhere onto one more country, plant or legal entity. The design questions are mostly settled; the work is localisation — legal and tax requirements, local processes, data migration and training — run on short cycles of a few months each. It is a classic environment for juniors to compound experience quickly: the same problems in a new context, again and again, until the template is second nature.

What happens after go-live: upgrades, clean-ups and AMS?

The system keeps changing for decades after the project ends. Focused technical programmes handle release upgrades, landscape consolidation, master-data harmonisation and moving custom developments to clean-core patterns; their scope is bounded and their outcomes measurable, which suits specialists and freelancers. Around them runs application management — incidents, small enhancements, monitoring, period-end support — the continuous form of SAP work and the ecosystem's most reliable entry door.

Who is on an SAP project team?

Whatever the shape, the team is organised the same way: by stream. Each SAP area — finance, procurement, sales, manufacturing — gets a functional stream with a lead and one or more consultants, usually mirrored by a business process owner and key users on the client side. Around the streams sit the cross-cutting teams: developers and an integration team for everything configuration cannot do, Basis for the systems and transports, data migration, a test manager who runs the integration test waves, and a change and training team. Above it all sit a project manager, a solution architect who owns the design across streams, and a steering committee that takes the decisions nobody else can. A greenfield build staffs every seat; a rollout reuses the template team with local functional support; AMS collapses the whole structure into a support organisation with the same areas as queues.

How do the shapes combine on one programme?

Rarely one at a time. A large programme is usually several shapes in sequence, and a job ad that names one is describing the phase it is hiring for. The common pattern is a greenfield or brownfield core followed by a rollout wave: the headquarters goes live on a template, then each country or plant is landed onto it, with the template team shrinking and the rollout team travelling. A conversion is often paired with a clean-up, because the custom code has to be sorted before the system can be converted, and the two are planned as one calendar. Every shape ends the same way, in a cutover and hypercare, after which the work becomes AMS whether or not the same people stay. The seat you take decides which shape you get credit for: the core build gives you design, the rollout wave gives you repetition and countries, and joining late for test or cutover gives you the go-live story.

Which project shapes belong on your record?

More than one, over a career, because hiring reads them as separate credentials: "greenfield design experience", "conversion experience" and "rollout experience" answer different questions, and greenfield teaches design, rollouts teach repetition to mastery, and AMS teaches what production does to a design. A record with at least one large build and some live-system time reads strongest. Name the approach and your seat in it on the CV, not only the programme (how experience is read).