ERD Import, Export, and Change Management

Use these workflows to bring an existing database structure into an ERD or deliver a reviewed model as documentation and migration SQL.

Before importing

Confirm:

• The schema contains no production secrets or real data
• Only the required schemas are included
• The database type and version match the project
• The import will not overwrite or duplicate an existing ERD unexpectedly

Check the available formats and options in the AiNecto web app. Schema import is performed on the web and is not requested as a direct Agent action.

Review the imported result

Check the expected table and column counts, primary and foreign keys, converted types and defaults, enums, indexes, relationships, naming conflicts, and duplicate tables.

Do not adopt an imported structure as the current standard immediately. Compare it with project documents and the actual system.

Export an ERD

Choose the purpose first:

• A schema for another tool
• An image or document for team review
• SQL for implementation
• A database specification describing the current model

Export using the formats available in the AiNecto web app, then reopen the result and check for omissions or broken content. Export is performed on the web.

Export a database specification

A database specification presents tables, columns, types, constraints, and descriptions in a form people can review.

Before exporting, confirm that descriptions, relationships, and terminology are current. Compare the generated specification with the project source of truth.

Migration SQL

Migration SQL turns differences between two states into an implementation change.

Before using it, confirm:

• The base and target versions are correct
• Whether any change may lose data
• Whether column deletion or type change requires separate migration work
• The service impact of index and constraint changes
• Backup and rollback plans

Check that Migration SQL generation is available in the current web interface. Treat generated SQL as a draft. Review and test it in a development or validation environment before applying it to a production database.

Record the outcome

Keep the ERD and actual system aligned by recording the reason for the change and its applied result.

Apply the confirmed decisions, risks, and follow-up actions from this ERD change to the Project Context document.

When ERD, OpenAPI, and implementation all change, update the current status of each related document.

Finally, reflect specialized-deliverable changes in the Markdown source of truth and Kanban follow-up work.