Introduction to SAP Solutions

Choosing the right SAP route from your current situation

This page is a map, not a product list. Most buyers arrive with a symptom rather than a product name: a finance close that runs too long, an ERP release nearing the end of its support, a development backlog nobody can staff, or a plant system that keeps its records on paper. The job of this section is to connect each symptom to the service area that deals with it first, so that the conversation starts in the right place. Each service area has its own page, and the table points to the one that matches the decision in front of you.

A good hub also tells you when you do not need the hub. If the question is a single upgrade in place on a release that is still supported, the SAP upgrade services page is the place to start. If it is one report or one interface, the technical services route is faster. Opening with a broad program when a narrow fix would do can be an expensive mistake.

Three situations where two routes overlap

Several SAP questions sit across two routes, and it helps to know which one should lead. The first is a migration with a sizeable custom code estate. The migration page covers the path, and the technical services page covers custom ABAP development, so the two are worth planning together. The second is a support contract for a system about to be upgraded. The support arrangement should state what changes during the upgrade, while the upgrade work carries the test and cutover plan. The third is a new integration layer. The architecture page covers landscape and integration design, and the technical services page covers integration build.

When you cannot tell which route should lead, that uncertainty is useful information in itself. It usually means the scope has not been written down, and the first deliverable of any engagement should be a short scope statement naming the decisions being made.

What a buyer should bring to the first conversation

The first is the problem in plain operational terms, such as which report is late, which approval waits or which system is out of support. The second is the current release and hosting model, even in outline. The third is the constraint that matters most, whether a budget window, a regulatory date, a shutdown period or a team that cannot be spared. These three items are enough to place the question in the right route without guessing.

If you already hold a current document describing the landscape, bring it, but do not wait to finish it before making contact. A partial picture discussed early is more useful than a complete one that arrives after the decision has been made informally.

What this hub does not decide

This page does not tell you which SAP product your organization is licensed for, whether a module is included in your contract or what the right budget is. Those facts sit with your SAP account team and your commercial terms. The hub also does not promise a fixed scope, duration or price for any route. The factors that move scope are the number of systems, the condition of the data, the amount of custom code and the number of people who must be trained.

Which SAP product should we start with if we are unsure?

Start with the problem and the date you need to act by. The product usually follows from those answers, and the route pages describe the products and modules in their areas.

Do we need one partner for every SAP route?

No. Some organizations use one partner for a migration and another for run support. What matters is that the boundary between them is written down, with each party’s responsibilities named.

How do we know if our SAP estate is too old to keep patching?

Check the published support dates for your release and whether your add-ons are available on newer releases. If either is close to its end, the question has moved from preference to planning.

Can we combine a technical review with a route decision?

Yes, and it is often the most efficient order. A short technical review produces the evidence a route decision needs and avoids choosing a route on assumptions.

How to sequence the routes across a planning cycle

Most SAP decisions are not made in isolation. They arrive inside a planning cycle, where a budget round, a fiscal close and a support contract renewal each pull in different directions. Sequencing matters because the routes depend on one another’s outputs. An architecture decision made after a migration has been committed forces rework. A support model agreed before the upgrade scope is known tends to be priced for the wrong workload. A technical backlog started before the data is cleaned tends to be rebuilt once the data changes.

A practical order for many buyers runs in four steps. First, establish the facts of the current estate: release, hosting, interfaces, custom code and the support arrangement that exists today. Second, decide the target shape, which means the architecture and, where relevant, the release path. Third, agree the delivery model, whether that is a full program, a targeted upgrade or a set of technical items. Fourth, set the run model, meaning who owns the system after go-live and how improvement work is funded. Each step produces a document the next step relies on, and skipping one usually means the missing document is produced later, under pressure.

Budget cycles create a particular trap. Finance teams often approve a single line for SAP and expect the partner to divide it. That works poorly because the routes have different cost shapes. Architecture and governance work is front-loaded and produces decisions. Build and migration work is spread across the middle of a program. Support is a recurring cost that continues after the project ends. Splitting the request into those three shapes makes the budget easier to defend and the scope easier to control.

Timing around fiscal close needs its own check. A cutover that lands in the last week of a financial year, or during an audit, carries a risk that the business rarely accepts once it understands it. It helps to mark the close calendar on the same timeline as the program plan before any date is discussed with a partner. The same check applies to support renewals: a new agreement that starts in the middle of an upgrade window is harder to test than one that starts after it.

Where to go next from this hub

Find the row in the table that matches the decision you face and open that route. If two rows seem to fit, the section above on overlapping routes shows which one should lead.