[{"content":"Highlights of each release, grouped by minor version. The upstream CHANGELOG.md carries the complete, detailed history — including the analysis behind each fix — and every tagged release is listed on the GitHub releases page.\n0.16.0 August 2026 Informix overhaul and a JDBC shutdown fix JDBC connectors no longer hang on exit. Worker threads now detach from the JVM together with their connection, so a migration that used to hang indefinitely after printing its summary finishes in under a second. Informix: system catalog no longer migrated. Discovery now separates user objects from the server\u0026rsquo;s own — one test database went from 534 routines and 89 tables down to the 17 routines and 24 tables the schema actually defines. Informix: many object types now migrate at all. Fixes for BSON/JSON columns, collection and row types, INTERVAL columns, descending and function-based indexes, check constraints, MERGE statements, global variables, and triggers — several of which previously failed the whole planning phase. Informix: MONEY migrates as NUMERIC with its precision and scale preserved, rather than as PostgreSQL\u0026rsquo;s very different MONEY type. 0.15.0 July 2026 T-SQL parser and validation depth Validation compares structure, not just data. Column, index and constraint counts are now extracted from both sides, persisted in the validation_indexes and validation_constraints protocol tables, and rendered as side-by-side grids in the Markdown report. Any mismatch fails the table validation. Sybase ASE / T-SQL parser hardening. Temporary # tables map to pg_temp, EXEC @id = func(...) becomes a proper PL/pgSQL assignment, legacy transaction directives and GOTO labels are neutralised, and cursor definitions spanning multiple lines are parsed correctly. Oracle moved to python-oracledb, replacing the outdated cx_Oracle. Thin mode is the default, so the Oracle Instant Client is no longer required. Validation connection exhaustion fixed — checksum engines no longer sever the validator\u0026rsquo;s long-lived connections mid-loop. 0.14.0 May 2026 Conflict resolution and a Sybase SQL parser data_conflict_action added to table_settings — choose replace, merge_keep_target, merge_keep_source or skip when data exists in both source and target. Implemented across all connectors. table_name accepts lists and regular expressions, so one directive can now cover many tables at once — uniformly across batch size overrides, chunking and selective migration toggles. Sybase ASE gained a real SQL parser for stored procedures, the same one previously used only for views — with a long list of T-SQL conversion fixes covering IF/ELSE nesting, UNION, PRINT, CONVERT datetime styles and inline conditionals. 0.12.x March – April 2026 Parallel view migration and DB2 z/OS aliases Views migrate in parallel via a thread pool, with alias views deliberately processed only after all standard views finish to avoid dependency collisions. DB2 alias resolution now labels an alias target as TABLE or VIEW in the catalog, preventing view-to-alias circular dependencies. CSV ingestion handles comma decimal separators, merging fields only where the target column is a scaled NUMERIC/DECIMAL/FLOAT. Fixes for check constraints (#57), sequence fetching on Informix, MySQL and Sybase (#63), view migration across most connectors (#65) and PostgreSQL-to-PostgreSQL data type substitution (#67). 0.11.x November 2025 – March 2026 Offline DDL connectivity and IBM DB2 z/OS New ddl connectivity type — database objects can be read from DDL files instead of a live connection, configured via ddl.directory. IBM DB2 z/OS support added through the new ibm_db2_zos connector; the existing DB2 connector was renamed to ibm_db2_luw. Sybase ASE conversion rewritten with a SQL parser for control flow, cursors and data types, plus support for legacy outer join syntax (*= / =*), user-defined types, OUTPUT to INOUT parameters and @@rowcount via GET DIAGNOSTICS. MS SQL Server gained view conversion with correct data types, user-defined type conversion and a first, usable version of trigger/function/procedure conversion. First version of the user documentation added to the docs/ directory. 0.10.x October – November 2025 Informix LOB import at scale Parallel LOB import for Informix. Informix exports each CLOB/BLOB into its own file (max 2 GB), referenced by pointers in the main UNL file. Sequential processing was workable up to about ten files; a configurable number of parallel workers now handles the hundreds of files that real tables produce. Multiple LOB columns per table are supported, and NULL LOB values are recognised whether they appear as the 0,0,0 placeholder or as a literal NULL. UNL to CSV conversion hardened against trailing backslashes, Windows \\r\\n line endings and escaped delimiters. MySQL gained ODBC and JDBC connectivity alongside the existing native driver. 0.9.x June 2025 PyPI distribution and sqlglot-based view conversion Published to PyPI via pyproject.toml, making pip install credativ-pg-migrator the standard installation route. sqlglot adopted for view conversion, starting with Sybase ASE, which significantly raised the view migration success rate. names_case_handling (lower, upper, preserve) is now honoured when generating CREATE statements — legacy engines disagree about identifier casing, and users need to choose. Data is selected by explicit column list instead of SELECT *, so awkward types (geometry, sets, LOBs, user-defined types) can be cast or transformed in the source query. Pre-migration analysis started — automating the questions that otherwise get asked of every client about their source database. 0.8.0 June 2025 First public release The initial public release of credativ-pg-migrator, with connectors moved into their own module directory. Older releases # Versions before 0.8.0 predate the public release. Their history is preserved in the full changelog.\n","externalUrl":null,"permalink":"/changelog/","section":"credativ-pg-migrator","summary":"Highlights of each release, grouped by minor version. The upstream CHANGELOG.md carries the complete, detailed history — including the analysis behind each fix — and every tagged release is listed on the GitHub releases page.\n","title":"Changelog","type":"page"},{"content":" Migrate legacy databases to PostgreSQL credativ-pg-migrator moves schemas, data, constraints, routines and views from proprietary and legacy database systems into PostgreSQL — with a migration protocol and post-migration verification that tell you exactly what arrived. Get started View on GitHub Why credativ-pg-migrator # Ten source databases, one tool Oracle, Informix, Sybase ASE, MS SQL Server, IBM DB2 (LUW, z/OS, i), MySQL, MariaDB, SQL Anywhere, SQLite and PostgreSQL — each behind its own connector, so engine quirks are handled where they belong.\nMore than tables and rows Primary keys, secondary indexes, foreign keys, check constraints, defaults, identity columns and sequences migrate along with the data. Views, functions, procedures and triggers are transpiled to PostgreSQL SQL and PL/pgSQL.\nVerified, not just copied Post-migration validation runs independent parity checks — row counts, full-table checksums, random row hashes and LOB byte sizes — plus structural comparison of columns, indexes and constraints, reported in a Markdown summary.\nBuilt for restricted environments Where a live connection is not an option, the migrator ingests offline DDL scripts and CSV extracts (IBM DB2 z/OS and i) or Informix .unl export files instead.\nCustomisable by configuration A single YAML file drives the run: data type substitutions, default value replacements, per-table WHERE filters, batch sizes and conflict resolution — no code changes needed to adapt to your schema.\nA full migration protocol Every migrated object is recorded in a PostgreSQL migration database with its source code, generated target code and outcome — so a failed object can be inspected and retried rather than guessed at.\nSupported source databases # Oraclelive connection Informixlive connection Sybase ASElive connection MS SQL Serverlive connection IBM DB2 LUWlive connection IBM DB2 z/OSoffline (DDL + CSV) IBM DB2 for ioffline (DDL + CSV) MySQLlive connection MariaDBlive connection SQL Anywherelive connection SQLitelocal file, no driver PostgreSQLspecial use cases How complete each connector is differs considerably. The feature matrix lists the per-connector, per-feature status — reconciled against the connector sources, not against a roadmap.\nTarget database: PostgreSQL.\nInstallation # From PyPI # python3 -m venv migrator_venv . ./migrator_venv/bin/activate pip install credativ-pg-migrator The package is published at pypi.org/project/credativ-pg-migrator.\nFrom the PostgreSQL APT repository # credativ-pg-migrator is included in the apt.postgresql.org PostgreSQL community repository — see the PostgreSQL APT wiki page for how to enable it on Debian and Ubuntu.\nRunning a migration # credativ-pg-migrator \\ --config=./test_database.yaml \\ --log-file=./test_database_$(date +%Y%m%d).log \\ --log-level=INFO Ready-to-use configuration examples for every supported source database are in docs/configs/ in the repository — copy the one matching your source, adjust the lines marked \u0026gt;\u0026gt;\u0026gt; ADJUST, and run it.\nArchitecture # The tool connects to the source database, introspects the data model, generates PostgreSQL-compatible structures and writes them into the target — coordinated by a central orchestrator running parallel workers. Read more on the documentation page.\nOpen source, with professional support # credativ-pg-migrator is released under the GNU General Public License v3 and developed in the open on GitHub. It is built and maintained by credativ GmbH, a PostgreSQL and open source consulting and engineering company.\nIf you are planning a database migration and want professional support — from an assessment of your source system to running the migration itself — please get in touch with credativ.\nGet involved # Bug reports, feature requests and pull requests are welcome. Whether you have a source database whose connector needs improvement or a conversion edge case that fails, an issue on GitHub is the right place to start. See Get Involved for details.\n","externalUrl":null,"permalink":"/","section":"credativ-pg-migrator","summary":" Migrate legacy databases to PostgreSQL credativ-pg-migrator moves schemas, data, constraints, routines and views from proprietary and legacy database systems into PostgreSQL — with a migration protocol and post-migration verification that tell you exactly what arrived. ","title":"credativ-pg-migrator","type":"page"},{"content":"This page is an overview to get you oriented. The full, maintained documentation lives in the repository — the User Guide covers every connector, option and limitation in detail.\nHow it works # credativ-pg-migrator is an offline migration tool. It connects to the source database, introspects the data model, generates PostgreSQL-compatible structures and writes them into the target instance. It is designed to run during a downtime or read-only window on the source, not as a live replication solution.\nIn practice the migration speed is limited by hardware and connectivity — experience shows the source database server is usually the bottleneck, not the migrator.\nComponents # Component Responsibility Parser Reads the YAML configuration file and the command line arguments. Planner Reads metadata and object definitions from the source and converts them into their PostgreSQL equivalents. Orchestrator Runs the migration steps and coordinates parallel workers. Workers Execute the data transfer and object creation in parallel. The three databases # A migration always involves three logical databases:\nSource database — any supported engine, accessed via ODBC, JDBC or a native Python driver. It does not have to be a server: a SQLite source is a plain local file, and a DB2 z/OS source can be a set of offline DDL and CSV files. Target database — the PostgreSQL instance where the migrated schema and data are created. PostgreSQL is the only supported target. Migration database — a PostgreSQL database holding the migration protocol: every migrated object with its source code, the generated PostgreSQL code, and a success or failure marker with timestamps. Usually this is the target database itself, but it can be a separate one. Installation # Python package # python3 -m venv migrator_venv . ./migrator_venv/bin/activate pip install credativ-pg-migrator The package is on PyPI: pypi.org/project/credativ-pg-migrator.\nDebian and Ubuntu # credativ-pg-migrator is part of the apt.postgresql.org PostgreSQL community repository. See the PostgreSQL APT wiki page for how to enable it.\nDepending on your source database you will additionally need the matching ODBC or JDBC driver. SQLite is the exception — it needs no driver installation at all.\nConfiguration # The migrator is driven by a single YAML file describing the source, the target, the migration database, which objects to migrate and how to convert them.\nThe fastest way to start is to copy the ready-made example for your source engine from docs/configs/ and adjust every line marked \u0026gt;\u0026gt;\u0026gt; ADJUST.\nA configuration file typically covers:\nSource settings — engine type, host, port, database, credentials, connectivity type (odbc, jdbc, ddl or native) and driver/JAR/DSN details. Target settings — PostgreSQL connection details and the default schema for migrated objects. Migration database settings — where the protocol tables are created. Object selection — which schemas to migrate, include/exclude lists for tables, views, sequences and routines. Data transfer options — per-table WHERE filters, batch sizes, conflict resolution and how foreign keys are handled during the load. Type and default value mappings — rules mapping source data types and vendor-specific default expressions to PostgreSQL equivalents. config_all_options_reference.yaml documents every option that exists and is the authoritative reference — but it is not a template. It lists mutually exclusive options side by side, so it cannot be used as a configuration file as it stands. Running a migration # credativ-pg-migrator \\ --config=./my_migration.yaml \\ --log-file=./my_migration_$(date +%Y%m%d).log \\ --log-level=INFO Logging goes to both the console and the log file. Two levels are available, INFO and DEBUG; on error a detailed message is printed. Rich information is written to the migration database in parallel.\nA typical migration project # Prepare PostgreSQL. Provision the target instance and decide whether the migration database is the same database or a separate one. Prepare connectivity. Install the required JDBC/ODBC/native drivers and verify the connection independently — for example with isql for ODBC — before involving the migrator. Write the configuration. Start from the example for your engine, fill in the connection details, select the schemas and tables, and add the type/default mappings and data filters you need. Run a test migration against a non-production target at INFO level. Inspect the log output, the protocol tables in the migration database and the resulting schema and data. Adjust and re-run. Refine mappings, filters and object selection until the result is what you expect. Run the production migration during a downtime or read-only window on the source, validate the result, then switch the applications over to PostgreSQL. The migration database # The migration protocol is one of the tool\u0026rsquo;s key strengths. For every migrated object it records the source and target names, the SQL used to create the target, the status (success, skipped, error) and timestamps — for tables, indexes, foreign keys, views, sequences and for functions, procedures and triggers including both their original source code and the generated PostgreSQL code.\nThat makes it possible to:\naudit exactly what was migrated and how; compare source code against the generated PL/pgSQL — the practical way to review the best-effort conversions before trusting them; rerun or manually fix individual objects without redoing the whole migration. Treat the migration database as read-only metadata: query it freely, but do not modify its tables directly.\nPost-migration validation # The migrator ships a validation engine that checks the target against the source independently of the migration itself:\nRow counts and full-table checksums for every live-connection source. Random row hashes and LOB byte sizes (currently Oracle, PostgreSQL and SQLite sources). Structural comparison of column, index and constraint counts, persisted in the validation_tables, validation_indexes and validation_constraints protocol tables. Results are reported as a Markdown summary with side-by-side grids; any mismatch flags the table validation as failed.\nFurther reading # User Guide \u0026amp; connectivity options — per-connector status, connectivity and limitations Feature matrix — which feature is supported by which connector Standard migration workflow Configuration examples Configuration parameters map ","externalUrl":null,"permalink":"/docs/","section":"credativ-pg-migrator","summary":"This page is an overview to get you oriented. The full, maintained documentation lives in the repository — the User Guide covers every connector, option and limitation in detail.\nHow it works # credativ-pg-migrator is an offline migration tool. It connects to the source database, introspects the data model, generates PostgreSQL-compatible structures and writes them into the target instance. It is designed to run during a downtime or read-only window on the source, not as a live replication solution.\n","title":"Documentation","type":"page"},{"content":"How complete a migration is depends heavily on the source database. The table below shows the per-connector, per-feature status. It mirrors FEATURE_MATRIX.md in the repository, which is the authoritative version and is reconciled against the connector sources — every entry corresponds to code that is actually present, not to a plan.\nLegend # Symbol Meaning yes Supported and successfully tested ? Implemented in general, needs better testing for this specific database WIP Work in progress, not yet supported -- Not implemented yet N/A Not supported by this source database (* = needs deeper verification) The hardest part of raising a ? to a yes is usually finding a test database that actually uses the feature in a realistic way.\nSupport by connector # Column abbreviations: DB2 LUW / z/OS / i = IBM DB2 variants, MSSQL = MS SQL Server, SQL Any. = SQL Anywhere, Sybase = Sybase ASE.\nFeature DB2 LUW DB2 z/OS DB2 i Informix MSSQL MySQL MariaDB Oracle PostgreSQL SQL Any. SQLite Sybase Pre-migration analysis WIP \u0026ndash;[9] \u0026ndash;[9] yes WIP WIP WIP WIP WIP WIP yes WIP Migration of data yes yes[9] yes[9] yes yes yes yes yes yes yes yes yes NOT NULL constraints yes yes yes yes yes yes yes yes yes yes yes yes Default values on columns yes yes yes WIP yes yes yes yes yes yes yes yes[4] IDENTITY columns yes yes yes yes yes yes yes yes[1] yes yes yes[8] yes Computed (generated) columns \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes yes yes yes \u0026ndash; yes[8] yes[5] Custom data type replacements yes yes yes yes yes yes yes yes yes yes yes yes Implicit default replacements[6] yes yes yes \u0026ndash; yes yes yes yes N/A yes yes yes Custom default value replacements yes yes yes yes yes yes yes yes yes yes yes yes Primary keys yes yes yes yes yes yes yes yes yes yes yes yes Secondary indexes yes yes yes yes yes yes yes yes yes yes yes[8] yes Foreign keys yes yes yes yes yes yes yes yes yes yes yes yes FK on delete action \u0026ndash; yes yes \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes yes \u0026ndash; yes N/A* Check constraints yes yes yes yes \u0026ndash; \u0026ndash; \u0026ndash; ?[7] yes \u0026ndash; yes[8] yes Check rules / domains[3] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; N/A N/A ?[7] ? \u0026ndash; N/A yes User-defined types \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; ? N/A N/A ?[7] yes \u0026ndash; N/A yes User-defined collations[12] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes \u0026ndash; N/A \u0026ndash; Full text search objects[13] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes \u0026ndash; N/A \u0026ndash; User-defined aggregates[14] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; N/A N/A \u0026ndash; yes \u0026ndash; N/A \u0026ndash; Comments on columns yes \u0026ndash;[9] \u0026ndash;[9] N/A* \u0026ndash; yes yes ?[7] yes \u0026ndash; N/A N/A* Comments on tables yes \u0026ndash;[9] \u0026ndash;[9] N/A* \u0026ndash; yes yes ?[7] yes \u0026ndash; N/A N/A* Migration of views ? ? ? WIP ? WIP WIP ?[7] yes WIP ?[8] ? Conversion of functions / procedures \u0026ndash; ? \u0026ndash; yes ? \u0026ndash; \u0026ndash; ?[7] yes \u0026ndash; N/A ? Conversion of triggers ? ? ? yes ? \u0026ndash; \u0026ndash; ?[7] yes \u0026ndash; ?[8] ? Sequences[2] ? ? ? \u0026ndash; ? N/A ?[10] ?[7] yes \u0026ndash; N/A N/A* Aliases / synonyms ? ? ? ? ? N/A N/A ? N/A \u0026ndash; N/A N/A SQL function mapping[11] WIP WIP WIP WIP WIP WIP WIP WIP N/A WIP WIP WIP Validation — row counts \u0026amp; checksums yes yes \u0026ndash;[9] yes yes yes yes yes yes yes yes yes Validation — random sample \u0026amp; LOB sizes \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes yes \u0026ndash; yes \u0026ndash; Notes # IDENTITY columns (Oracle). Recognised via the sequence used as the default value. Data types remain an issue: Oracle allows a primary key on NUMBER with a sequence, while a PostgreSQL identity column must be INT or BIGINT. Sequences. Not migrated as standalone objects for most engines. SERIAL/BIGSERIAL, identity columns and columns with a sequence default become PostgreSQL identity columns, so the sequence is created automatically and its current value is set from the migrated data afterwards. Oracle additionally migrates standalone sequences as independent PostgreSQL sequences (see note 7). Check rules / domains. Externally defined checks bound to a column or data type — domains in PostgreSQL, rules in some other engines. Currently being implemented for Sybase ASE. Sybase ASE defaults. CREATE DEFAULT creates a named default that can be attached to several columns. PostgreSQL has no equivalent, so the underlying default value is attached directly to each target column. Sybase ASE computed columns. Sybase creates hidden computed columns for function-based indexes (e.g. sybfi4_1 AS LOWER(ProductName) MATERIALIZED), which also changes the index DDL stored in the system tables. Implicit default replacements. Common default values whose syntax PostgreSQL does not accept are replaced implicitly during migration. Oracle. Check constraints, standalone sequences, user-defined types, domains, table/column comments, views/materialized views and best-effort PL/SQL conversion are implemented but not yet validated against a live database. PL/SQL conversion is heuristic: packages are split into standalone \u0026lt;package\u0026gt;_\u0026lt;routine\u0026gt; functions with call sites rewritten (package state is not migrated), triggers become a PL/pgSQL trigger function plus CREATE TRIGGER, and complex constructs are flagged for manual review. Object types become composite types; collection types (VARRAY, nested tables) become array-based domains. SQLite. SQLite has no data dictionary for several of these objects, so check constraints, generated column expressions, AUTOINCREMENT markers and functional index expressions are parsed out of the CREATE statements in sqlite_master. Views, triggers and expressions are translated with sqlglot plus a SQLite-specific function mapping. Partial indexes lose their WHERE condition (recorded in the index comment) and a partial unique index is degraded to a non-unique index. Virtual tables (FTS, RTREE, …) and their shadow tables are skipped. Because SQLite is dynamically typed, values are coerced to the target column type during data migration. IBM DB2 z/OS and DB2 for i. These are offline connectors — they never connect to the source instance. Structure is read from .sql/DDL extracts (connectivity: \u0026quot;ddl\u0026quot;) and data from source-generated CSV files. Anything requiring a live source (pre-migration analysis, random-sample and LOB-size validation) is therefore unavailable. COMMENT ON / LABEL ON statements are parsed out of the DDL and stored in the protocol tables, but are not yet applied to the target. MySQL and MariaDB. Separate, largely identical connectors. MariaDB additionally migrates standalone SEQUENCE objects (MariaDB 10.3+). Neither converts functions, procedures or triggers. SQL function mapping. Every connector ships a mapping of common source SQL functions to PostgreSQL equivalents, applied when defaults, views, constraints and routine bodies are converted. Coverage differs per engine and is extended on demand — hence WIP everywhere. No mapping is needed for a PostgreSQL source. User-defined collations. Standalone CREATE COLLATION objects referenced by columns and indexes, migrated for a PostgreSQL source (ICU and libc provider, locale, tailoring rules, non-deterministic collations, comment). Collations of other engines (utf8mb4_general_ci, Latin1_General_CI_AS, …) have no PostgreSQL counterpart, so the reference is dropped and the column keeps the target database default. Full text search objects. Dictionaries and text search configurations referenced by generated tsvector columns, views, indexes and functions. Migrated for a PostgreSQL source including the complete token type mapping; references inside 'name'::regconfig literals are rewritten. Objects belonging to an extension are not migrated — they come with the extension. User-defined aggregates. CREATE AGGREGATE objects, migrated for a PostgreSQL source with their state transition, final, parallel and moving-aggregate support functions, initial conditions, sort operator and parallel safety. Created after the functions and procedures they reference. Aggregates provided by an extension are not migrated. Tested database versions # Source database Tested version IBM DB2 LUW latest IBM DB2 z/OS DDL + CSV extracts (offline, no live instance) IBM DB2 for i DDL + CSV extracts (offline, no live instance) Informix 14.10 MS SQL Server 2022 MySQL 5.7 MariaDB not yet validated against a live instance Oracle 21.3 PostgreSQL 14, 17 SQL Anywhere 17 SQLite 3.46 Sybase ASE 16.0 Missing a source database or a feature you need? Support can be added on demand — see Get Involved.\n","externalUrl":null,"permalink":"/features/","section":"credativ-pg-migrator","summary":"How complete a migration is depends heavily on the source database. The table below shows the per-connector, per-feature status. It mirrors FEATURE_MATRIX.md in the repository, which is the authoritative version and is reconciled against the connector sources — every entry corresponds to code that is actually present, not to a plan.\n","title":"Feature Matrix","type":"page"},{"content":"credativ-pg-migrator is open source under the GPLv3 and developed in the open. Contributions are welcome, and they do not have to be code.\nReport a problem # The most valuable contribution is a well-described failure. Legacy databases are endlessly inventive, and the conversion logic can only cover what it has seen.\nOpen an issue on GitHub and include:\nthe source database engine and version, and the connectivity type you used (odbc, jdbc, ddl or native); the relevant part of your configuration file — with credentials removed; the log output around the failure (--log-level=DEBUG gives considerably more detail); for a conversion problem, the original object definition and the generated PostgreSQL code. Both are stored side by side in the migration database protocol tables, which makes them easy to extract. Contribute code # Pull requests are welcome — for a new source database connector, better coverage of an existing one, or a fix for a conversion edge case.\nA source database connector implements the DatabaseConnector class from the credativ_pg_migrator.database_connector module. Its methods document the expected behaviour and return values, so the class is the place to start when adding an engine. Sources are reached via ODBC, JDBC or native Python libraries — not every option is available for every engine.\nThe feature matrix is a good map of where the gaps are: every --, WIP and ? is work that has not been done or not been verified yet. The ? entries in particular are usually blocked on one thing — finding a test database that uses the feature realistically. If you have such a schema, that alone is a real contribution.\nImprove the documentation # Documentation lives in the docs/ directory of the repository, next to the code. If something was unclear or missing when you ran your migration, a pull request against those files helps the next person.\nProfessional support # If you are planning a migration and want it handled rather than done yourself, credativ GmbH offers professional support for PostgreSQL and database migrations — from assessing the source system through to running the migration.\nGet in touch with credativ.\nAuthors and license # credativ-pg-migrator was primarily developed and is maintained by Josef Machytka at credativ GmbH — see AUTHORS for the full list.\nThe project is released under the GNU General Public License, version 3 (or any later version). See COPYING for the full text.\n","externalUrl":null,"permalink":"/get-involved/","section":"credativ-pg-migrator","summary":"credativ-pg-migrator is open source under the GPLv3 and developed in the open. Contributions are welcome, and they do not have to be code.\nReport a problem # The most valuable contribution is a well-described failure. Legacy databases are endlessly inventive, and the conversion logic can only cover what it has seen.\n","title":"Get Involved","type":"page"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]