SAP PowerDesigner ends in 2027: what happens to your data models?

SAP has announced the end of mainstream maintenance for PowerDesigner: at the end of 2027 the product moves into customer-specific maintenance. The exact date per release sits in SAP’s Product Availability Matrix and in KBA 3280082, behind an SAP login. Check it for your own version, because older releases such as 16.5 and 16.6 reached their end-of-life dates earlier.

Anyone who spent the last few years waiting for a new feature already knew: version 16.7 shipped in April 2020, and only service packs followed. For a tool whose job is to keep up with the databases underneath it, the absence of a new major version is the real signal. So you are leaving. The question is what happens to the models you already have.

What actually stops

PowerDesigner does not switch off on the end date. Your installation keeps running and your model files stay readable. What disappears is the maintenance: no security patches, no bug fixes, and no certification for new versions of the databases underneath.

That last limitation weighs heaviest. A modelling tool that no longer moves with Oracle, SQL Server, PostgreSQL or Snowflake slowly becomes unreliable. You end up modelling against a target platform the tool does not officially know, and every difference that follows from that has to be caught by hand. The model drifts away from reality, and a data model that no longer matches is worse than no model at all when an audit arrives.

What does and does not carry over to erwin Data Modeler

This is where most migration plans are too optimistic. An honest split in three:

Transfers cleanly. Physical models: tables, columns, keys, indexes and relationships. DDL generation. Reverse engineering against the existing databases.

Transfers partly. Logical and conceptual models, domains and naming conventions. The content moves, but the standards have to be set up again in erwin’s own naming standards and model templates.

Does not carry over. Custom GTL templates and extensions: PowerDesigner’s Generation Template Language has no direct equivalent in erwin and has to be rebuilt on erwin’s own generation and macro mechanism. Repository history and version branches do not transfer either. And the important one: UML class models (OOM) and process models (BPM) have no destination in erwin Data Modeler. It is a data modelling tool, not a UML or BPMN environment. If PowerDesigner is also your process repository, that part needs its own answer.

The practical advice that follows: for your physical models, do not convert the old file. Pull the model out of the live database again. The database is the most reliable source, and you start clean instead of inheriting ten years of model history. The logical layer goes back on afterwards.

What erwin brings back in return

Against that rebuild work sits what you gain, and most of it addresses exactly the problem an unmaintained PowerDesigner leaves you with.

The heaviest item is the comparison between model and reality. erwin Data Modeler puts a model next to a live database or next to another model, shows the differences and synchronises them in either direction. Where you now have to track by hand whether the model still matches, drift becomes something you switch on and read off. Impact analysis comes with it: before you change a column or a key, you see which objects and data flows sit underneath.

One tool also covers the whole landscape. Forward and reverse engineering work against Oracle, SQL Server, DB2, MySQL, PostgreSQL, Snowflake and Google Cloud AlloyDB, so on-premise and cloud are modelled in the same environment and under the same standards. Naming conventions and modelling standards are defined centrally and enforced by the tool, rather than living in a Word document. Reports and model overviews are generated by erwin itself, with nobody maintaining them.

For teams the gain sits in the Workgroup repository. Several modellers work on the same model with version control, conflict resolution and role-based rights, and no longer with model files sitting side by side on a network share. Reviewers and stakeholders get read access and impact analysis through the Navigator edition, without a full modelling licence.

Then the step PowerDesigner never took: erwin Data Modeler shares its metadata bidirectionally with erwin Data Intelligence. Models, definitions and relationships land in the governance catalogue, with lineage and business context attached. Data ownership, definitions and reporting then rest on one source rather than on three separate administrations. For organisations running a governance programme that is the real gain of the move, bigger than replacing the tool itself.

Planning backwards from the deadline

Four steps, in this order.

1. Take inventory. Which model types exist, how many models there are, and which ones are genuinely maintained. In practice a large share of a PowerDesigner estate is dead wood. Separating the two is the cheapest win in the whole project.
2. Trial conversion on one domain. Take one representative model and measure what breaks. This is the only step that produces a reliable estimate for the rest.
3. Tool and licence choice. With erwin Data Modeler, the way your team works determines the edition mix: Standard for the individual modeller, Workgroup for a team on a central repository, Navigator for stakeholders who only review.
4. Cutover and agreements. Where the model lives, who owns it, and how it stays in sync with the database. Without those agreements you are in the same place in three years with a different tool. That belongs to data governance.

Start in 2026. A migration competes with your own release calendar, and 2027 will be just as full as this year. Teams that start in the final months skip step 2 and carry the risk into the cutover.

When erwin is not the answer

We are an erwin by Quest partner, so read our weighting critically. Even so: erwin Data Modeler is not the logical successor in every case.

If PowerDesigner is mainly your UML and process repository, you are looking at the wrong category of tool. If you work with two or three modellers, physical models only and no governance ambition, a lighter tool is probably enough. If your whole landscape runs on a single cloud platform, the first question is whether native modelling plus a metadata catalogue already covers it.

erwin earns its place where the opposite holds: modelling across multiple platforms, a shared repository with version control and roles, and the link to governance and lineage. That is the profile of most PowerDesigner installations we come across, but not of all of them.

What cimt does

We run the inventory and the trial conversion, so you have a grounded estimate before you buy licences. If erwin is the right destination, we handle licence advice, procurement, setting up the repository and training the team. If it is not, we say so.

To request a migration inventory, use the form on the erwin Data Modeler page or contact [email protected] directly.