We design, blueprint and govern SAP transformation — ERP strategy, S/4HANA transition, clean-core and BTP architecture, data migration and programme management.
Our revenue comes from advice alone. The design you get is the one your business case needs, not the one that fills a delivery bench.
"The system integrator owns the design, the plan and the definition of done."
A blueprint and target architecture you own. The integrator builds to your design, and is measured against it.
"Custom code welded into the core turns every upgrade into a re-implementation."
A clean core with extensions on BTP. Upgrades become a scheduled step, not a programme.
"The business case was approved two years ago and nobody has measured it since."
Benefits defined, baselined, instrumented and reported monthly — independently assured.
SAP has set the dates in writing. They are worth knowing precisely, because the gap between them is the window in which a considered transition is still possible — and outside which the options narrow to expensive ones.
Source: SAP maintenance strategy for SAP S/4HANA and SAP Business Suite 7, support.sap.com. Verify against SAP before quoting in a board paper — SAP has adjusted these terms before.
Scroll the timeline sideways to see through to 2040.
This is the first question every client asks, so it is worth answering plainly. We are the client-side design and governance capability. Integration, resale and licence margin all sit outside our model, so the outcome carries no commercial pull for us.
Scroll sideways to see all five stages.
Seven capabilities. Each one is a discrete piece of work with its own deliverable, and each can be bought on its own or run as a continuous programme role.
What the platform is for, what it must change, and whether the numbers hold.
Greenfield, brownfield or selective — chosen on evidence, not on the integrator's preference.
The design the integrator builds to — written from your processes, not from a template.
Where each extension belongs, and why — so the estate stays upgradeable.
The most common cause of a delayed go-live, governed as its own workstream.
Client-side control of a programme delivered by someone else.
The part that answers "did it pay off" with a number rather than an opinion.
A configured system nobody uses properly delivers none of its case.
Evidence rather than status reports, throughout the journey.
Most programmes are pushed toward the option that suits the delivery partner. The right answer depends on how much of the business you actually intend to change, and how much of your existing configuration is worth keeping.
| Approach | What happens | Suits you when | Main risk |
|---|---|---|---|
| Greenfield New implementation |
A new system is built to a new design. Only the data you choose comes across. | Your processes need to change substantially, the existing configuration carries decades of debt, or the business is restructuring anyway. | Scope grows. Without a disciplined blueprint and a hard fit-to-standard rule, you rebuild the old mess on new software. |
| Brownfield System conversion |
The existing system is converted in place. Configuration, history and custom code come with it. | The current design is broadly sound, the timeline is tight, and the priority is getting onto a supported platform. | You inherit the technical debt. Custom code that was never remediated becomes the reason the next upgrade is a project. |
| Selective Data transition |
A new system is built, then chosen configuration and data are migrated into it, entity by entity or process by process. | You have a large multi-entity estate, need to phase by business unit, or want to keep some designs and discard others. | Complexity and cost. It needs stronger data governance and architecture discipline than either alternative. |
We are option-neutral by design. The recommendation comes out of the readiness assessment and the business case, and we have no delivery revenue riding on which one you pick.
"Clean core" gets used loosely. In practice it means one decision, made consistently: for every extension, does it belong inside the ERP or beside it? Get that decision right and upgrades stay routine. Get it wrong and every future release becomes a regression-testing programme.
Scroll sideways to see the full architecture.
Architecture reflects SAP's in-app versus side-by-side extensibility model. Product names change — SAP has renamed several BTP services in recent years, so confirm current naming before publishing.
We decide what should exist, where it should sit, the boundaries it holds to, and how anyone will know later whether it earned its keep. The integrator or your platform team builds to that.
Which systems talk to which, through what contract, and who owns each interface. API-first, with the point-to-point connections that quietly accumulate over a decade designed out rather than tolerated.
A written rule for every extension: in-app on ABAP Cloud, side-by-side on BTP, or not built at all because standard already does it. This single register is what keeps a core clean over time.
Automation applied where the process evidence says it pays — measured in manual touches removed and cycle time recovered, with the baseline captured before anything is built.
Where the reporting truth lives, how it stays reconciled with the core, and what has to be governed for the numbers to be defensible at audit.
Which processes are stable and well-instrumented enough to carry an agent, and which need redesign first. The unglamorous answer is usually "fix the process, then automate it".
Landscape, environments, entitlements, cost control and the standards the build partner is contractually held to — so BTP does not become the new place where technical debt hides.
Most clients start at the assessment and continue into whichever roles they need. Nothing here requires you to buy the whole thing.
Where the estate stands, what the transition would actually involve, and whether the business case holds. Fixed scope, fixed fee.
Transition approach, target architecture, process blueprint and the benefit baseline the programme will be measured against.
Client-side PMO, integrator oversight, architecture conformance and stage-gate assurance through build, test and cutover.
Post-go-live conformance, adoption and drift tracking, with monthly benefit reporting until the case is proven or formally revised.
A twin is simply a living, data-fed model of something real — current enough to trust and detailed enough to test decisions against.
VCG Advisory supported a multi-billion-dollar ERP transformation for the Commonwealth Government of Australia, developing detailed business blueprints, data architectures, and a digital twin of operations to optimise decision-making. Through data cleansing, validation, and reconciliation, we delivered tangible improvements in accuracy, efficiency, and control. Technologies included SAP S/4HANA, SAP BTP, and ARIS — enabling integrated insights and measurable performance uplift.