Migrating From PowerDesigner

DbSchema has no PowerDesigner importer - Model > Import from External Format accepts SQL DDL, CSV, XML, XLS and JSON only - so the route off SAP PowerDesigner is the DDL its physical model generates. Deploy that script to a staging database, reverse-engineer it over JDBC, and the tables, columns, keys, indexes, constraints and comments arrive as an interactive ER diagram. VBScript automations, custom extended attributes and repository permissions do not come across. This guide covers the import path, what carries over, and what has to be rebuilt.

What exists in the source tool

SAP PowerDesigner is a collaborative enterprise modeling suite organized around a separation of conceptual, logical, and physical model layers. It started life as AMC*Designor in France, was renamed PowerDesigner after Powersoft acquired its original vendor SDP in 1995, and passed to Sybase and then to SAP, which acquired Sybase in 2010[1]. Enterprise database architects rely on this layered structure to govern data models across varied database targets.

Understanding how PowerDesigner structures these assets clarifies what must be preserved during a migration:

• Conceptual Data Models (.cdm): Define entity-relationship structures using business terminology, independent of hardware, software, or storage specifications.
• Logical Data Models (.ldm): Resolve many-to-many relationships and define domain constraints while remaining neutral to specific relational database management systems.
• Physical Data Models (.pdm): Map logical entities to concrete database objects including tables, foreign keys, triggers, indexes, and engine-specific storage parameters.
• Business Process Models (.bpm): Document operational workflows and data flow pipelines across business departments.
• Enterprise Architecture Repository: Stores shared model definitions in a centralized database for multi-user governance and impact analysis.

When transitioning off SAP PowerDesigner, architects must separate core relational structures from proprietary repository metadata and business process diagrams.

What carries over

Standard relational database structures migrate cleanly from SAP PowerDesigner into DbSchema. Because physical models in PowerDesigner compile into standard SQL DDL, every core schema definition transfers without data loss. The same clean structural transfer applies to what carries over when you leave ERwin, which deploys the same SQL-standard definitions into a unified design file.

The following schema elements transfer directly into the new model:

The Architect Edition represents these objects across both database-independent logical models and target-specific physical designs. Relational integrity, data types, and primary-foreign key hierarchies carry over completely.

What has to be rebuilt

Proprietary metadata formats, custom automation scripts, and vendor-locked repository configurations do not translate automatically between modeling tools. These elements have to be reconfigured in the target tool using modern scripting and visual model rules.

• VBScript Automations: PowerDesigner uses proprietary VBScript macros for custom validations and transformations. Rewrite these tasks as Groovy automation scripts or built-in model validation rules.
• Custom Extended Attributes (XDB/XEM files): Custom XML metadata extensions must be re-established as column comments, custom tags, or model properties.
• Physical Storage Configurations: Engine-specific tablespace allocations, memory buffer pools, and raw partition definitions must be reapplied in target deployment DDL.
• Repository Permissions: Sybase-based repository user groups are replaced by standard Git branch permissions and pull request review workflows.
• Custom Report Templates: PowerDesigner RTF and web reports are replaced by interactive HTML5 documentation exports.

Rebuilding these items modernizes your workflow by substituting legacy proprietary macros with version-controlled Groovy scripts and Git-managed schema definitions.

The order of the steps

Migrating off SAP PowerDesigner onto DbSchema follows a five-step execution sequence. Complete each stage in order to maintain structural integrity throughout the transition.

1. Generate Physical DDL: Open your Physical Data Model (.pdm) in SAP PowerDesigner. Export the complete physical schema to clean SQL DDL files, or apply the schema directly to an isolated staging database.
2. Connect via JDBC: Establish a connection to your staging database using DbSchema's built-in JDBC driver manager, or run a model import from your generated DDL files.
3. Reverse-Engineer the Schema: Select all target schemas, tables, views, and routines. DbSchema reads the database catalog and constructs the complete visual ER diagram automatically.
4. Organize Sub-Diagrams: Divide large schemas into focused sub-diagrams by business domain or microservice module. Add virtual foreign keys for logical relationships not enforced at the database engine level.
5. Save and Version the Model: Save the project as an offline design model file and commit it to your team Git repository for peer review.

Following this sequence ensures that all relational definitions, constraints, and descriptions transfer accurately before you decommission the legacy tool.

What is the alternative to Liquibase?

Visual schema synchronization is the practical alternative to code-first migration utilities like Liquibase. Liquibase changelogs can be written in SQL, XML, YAML, or JSON, and when a root changelog uses the include or includeAll tags to reference other changelogs, that root file must be an XML, YAML, or JSON file[2]. DbSchema instead compares your design model directly against live database environments, the approach shared by other Liquibase alternatives with a visual schema diff.

Architects managing complex enterprise databases can review visual diffs and generate safe deployment scripts from the model itself, without hand-authoring changelog files.

What is the alternative to Lucidchart?

DbSchema is the closer replacement for general-purpose diagramming suites like Lucidchart, and the same reasoning runs through the wider field of Lucidchart alternatives for database diagrams. Lucidchart functions as a canvas for static vector shapes, whereas DbSchema connects directly to live engines and keeps the data model synchronized with the catalog.

• DbSchema: Connects directly to a wide range of SQL and NoSQL engines via JDBC. It introspects live catalogs, enforces data types, manages foreign key hierarchies, executes visual SQL queries, and generates deployment scripts.
• General drawing tools (Lucidchart, Visio): Offer static drawing canvases without native database connectivity, schema validation, or SQL DDL generation. Diagram shapes quickly desynchronize from actual production schemas.

For database architects migrating off SAP PowerDesigner, moving to a static drawing tool introduces manual maintenance overhead - the same trap as moving a dbdiagram.io schema to a connected model. DbSchema preserves the active relationship between the visual diagram and the physical database catalog.

Validating the migrated design model

Validate the imported structure before rolling out the new design to development teams. Save the complete architecture as an offline.dbs file, which stores table definitions, layout coordinates, sub-diagrams, and virtual foreign keys in plain XML format.

• Run Model Validation: DbSchema ships no built-in rules, so author your own. The available checks test names and descriptions - name is lowercase, name is uppercase, name starts with, name matches a regular expression, has description - which catches naming-convention drift across all schemas; anything structural needs the Java Groovy check.
• Commit to Git: Track model evolution by committing the.dbs project file to your Git repository. Review visual schema diffs directly inside pull requests.
• Publish Interactive Documentation: Export full HTML5 documentation containing vector diagram layouts, searchable data dictionaries, and mouseover column comments.

To start your migration, download DbSchema, connect to your staging database or load your exported SQL DDL, and open the model against your own database. The Architect Edition adds the database-independent logical and conceptual design layer on top of the physical model.

Frequently asked questions

What is the alternative to Liquibase for database migrations?

Liquibase tracks changes through hand-written changelogs in XML, JSON, YAML, or SQL. DbSchema compares an offline design model directly against a live database, highlights the differences, and generates the exact SQL migration script required.

What is the alternative to Lucidchart for database design?

DbSchema is the functional alternative. Lucidchart creates static pictures using shape libraries, so it cannot reverse-engineer databases or write SQL, whereas DbSchema connects to live databases over JDBC to build interactive, executable ER diagrams.

How do I export an SAP PowerDesigner model?

The most reliable migration path is to generate the complete physical database DDL script from SAP PowerDesigner, deploy that schema to a staging database, and then reverse-engineer the live database into a new offline design model.

What components carry over from SAP PowerDesigner?

Standard relational database structures migrate cleanly. This includes tables, columns, standard SQL data types, primary keys, and foreign keys. These core structural elements form the foundation of the newly synchronized project.

Which PowerDesigner features have to be rebuilt?

Proprietary configurations do not carry over. Database architects must manually rebuild custom VBScript automations using Groovy scripting, and redefine highly specific physical storage options that were isolated within PowerDesigner's internal physical data model.

Sources

1. powerdesigner.biz
2. docs.liquibase.com