SAP Build Work Zone: what migrates

The conversation about SAP Build Work Zone almost always starts wrong. Someone shows the new screen, praises the look, and the decision becomes aesthetic. It is not. It is a deadline.

SAP Enterprise Portal is out of mainstream maintenance, and with it the Fiori Launchpad hosted on the portal. Anyone running a legacy portal is not choosing whether to migrate — only when. And the difference between choosing now and being pushed later is how much gets lost along the way.

In one sentence — Work Zone is not the portal with a new face: it is a different assembly model, and what the portal solved with a custom page is solved here with spaces, pages and cards. Whatever has no equivalent must be rebuilt, and that is what projects usually discover late.

What actually changes

In the portal, the unit was the page: someone built one, dropped iViews inside, and navigation came from a folder structure with permissions of its own. In Work Zone the unit is the space — a slice by role, not by subject — holding pages made of cards.

It looks like renaming. It is not. In the portal, permission lived in the navigation structure; in Work Zone it comes from the business role that assigns the space. Teams that migrate the screen without migrating the permission model find out on day one in production, when half the users see what they should not and the other half cannot find what they need.

What does not cross over on its own

Legacy portals hold four categories of content, and they behave very differently in a migration.

Fiori applications and SAP GUI transactions cross well. This is the happy case: the catalog already exists, the target is already mapped, and the work is reorganising rather than rebuilding.

URL iViews and external content cross with adjustment. They become link cards or web applications, and what usually breaks is authentication — what worked on a portal session now has to work on a token.

Web Dynpro Java iViews are the problem. There is no direct path, because the runtime that executes them belongs to the portal itself. Each one needs a decision: rewrite, replace with an SAP standard, or retire. This is where schedules blow up, and it is the first thing worth inventorying.

Theme and branding customisation does not cross. Work Zone has its own theming engine, and what was CSS in the portal has to be rebuilt in the new tool.

Worth watching — there are two editions, and the difference is not size. Standard delivers the launchpad and spaces; advanced adds collaborative workspaces, external content integration and workflow. Buying standard while expecting collaboration is the most common scoping error — and it surfaces after the contract is signed.

The order that avoids rework

Sequence matters more than tooling. Invert the first two steps and you rebuild everything twice.

First, inventory what actually exists. Not the portal’s page list — the list of what is used. Six months of access logs usually reveal that half the portal has not been opened by anyone in years, and migrating that is paying to carry dead weight.

Second, design the spaces by role. Before touching any screen. A space is a slice for whoever uses it, not for whoever built it — and that conversation belongs to the business, not to IT.

Third, rebuild the catalog. Take the chance to clean up: a catalog carrying ten years of exceptions is the moment to rationalise, because dragging the mess costs the same as tidying it.

Fourth, handle each Web Dynpro Java one by one, with the decision on record. Rewrite, replace or retire — and the process owner decides, not the technical team.

Fifth, run both in parallel before switching off. Portal and Work Zone living side by side for a few weeks, with a real group using them, is what surfaces whatever the inventory missed.

Where AI genuinely helps

Not in the migration itself — that is structural, not interpretive. Where it pays off is the inventory: reading the portal navigation structure, cross-checking it against usage logs and proposing the first mapping of spaces by role is exactly the kind of bulky, repetitive reading where automation saves weeks.

What it will not do is decide what to retire. That decision has an owner, and the owner is the business.

The honest limit

Work Zone does not fix a bad process. If an approval passes through four people today because nobody trusts the control, it will pass through four people with a nicer interface. The migration is a good occasion to review that — it is not the review.

And it is not a project of weeks. A legacy portal with ten years of content, treated honestly, is months of work — most of it spent deciding, not configuring.

At Inove this kind of migration sits in the same SAP practice design where we handle roles, catalogs and authorisation: what sets the deadline is not the tool, it is how much of today’s content someone is willing to retire.

Frequently asked questions

What is SAP Build Work Zone?

It is the entry layer to SAP: where people find the applications, transactions and content they need, organised by role. It succeeds the Fiori Launchpad hosted on Enterprise Portal, with its own model of spaces, pages and cards.

What is the difference between the standard and advanced editions?

Standard delivers the launchpad and the organisation into spaces and pages. Advanced adds collaborative workspaces, external content integration and workflow. The difference is function, not volume — and buying standard while expecting collaboration is the most common scoping error.

What does not migrate from Enterprise Portal?

Web Dynpro Java iViews, because the runtime that executes them belongs to the portal, and all theme customisation, because Work Zone has its own theming engine. Fiori applications and SAP GUI transactions cross well; URL iViews cross with an authentication adjustment.

Where should the migration start?

With an inventory of what is actually used, not of the page list. Six months of access logs usually show that much of the portal has not been opened in years. Migrating that is paying to carry dead weight — and an honest inventory is what shortens the schedule.

How long does it take?

A legacy portal with ten years of content is months of work, and most of the schedule sits in decisions rather than configuration: what to rewrite, what to replace and what to retire. Projects promising weeks are usually migrating the screen and postponing the permission model.