You cannot migrate a database estate you have never counted

Every migration that starts badly starts with the same document: a spreadsheet.

Someone exports a server list from an old CMDB. Someone else adds a column called criticality. By the second planning meeting, budget and timeline are being estimated from numbers nobody can defend. Two of the databases were decommissioned last year. Three production clusters are missing because they were built outside the standard process. The version column says 12 for every host, which is true for four of them.

You can debate migration tooling for weeks. The larger risk is the inventory it gets pointed at.

Scoping is where migrations are won or lost

Database migration methods are fairly standard, and the first step is nearly always the same: scoping. Before anyone argues about which workload moves first, you need a schema inventory and a complexity assessment. That step quietly assumes you already know what you own.

This is the assumption that breaks. It is hard to size a project from gossip.

What a usable inventory contains

A working inventory answers a short list of questions for every instance, and it answers them from the machine rather than from memory:

Where the host is, and how to reach it
Which database version is running, and whether it is patched
What operating system it runs on
Which environment tier it belongs to: development, QA, or production
Its role in the cluster, leader or replica
Whether it answered the last health check
Who owns it when something goes wrong

None of these fields are exotic. Most estates still lack an accurate version of this list, which is why step one of a migration programme so often turns into archaeology.

A free starting point: PG-Inventory

PG-Inventory is Worlber's open-source PostgreSQL inventory and monitoring platform. It is published under the MIT licence and the source is at github.com/Worlber/PG-Inventory.

It deploys with Docker Compose, requiring Docker Engine 20.10 or later and Compose v2 or later, and runs as six services. The stack is a React 18 and TypeScript front end, a Django 5.1 back end on Python 3.12, PostgreSQL 16 for its own storage, and Redis 7 with Celery and Celery Beat for scheduled work.

What it does with your instances:

Registers databases and lets you add, edit, and delete entries, with credentials encrypted using AES-256-GCM
Groups instances into development, QA, and production categories
Probes every instance on a two-minute interval and reports status, version, operating system, CPU, and memory
Marks an instance DOWN after three consecutive failed checks
Polls the Patroni REST API to show leader and replica roles and a visual cluster topology
Applies role-based access control with Admin and Viewer roles, plus TOTP two-factor authentication
Exports to CSV and Excel, with global search across the inventory

For a team that currently maintains its instance list in a spreadsheet, that is a meaningful upgrade: the list updates itself, and the credentials sit encrypted in a database you control instead of in a shared file.

What PG-Inventory is not

Worth stating plainly, because inventory tools get oversold:

It inventories PostgreSQL. It will not enumerate Oracle, SQL Server, or DB2 estates.
It tracks Patroni cluster state. It does not provide high availability. HA is a separate layer, and running it is a different job.
An inventory is not an assessment. It tells you what exists. It does not tell you which stored procedures will break, which queries will lose their plan, or which application will need code changes.
It is open source and self-hosted, so you carry the deployment and the upgrades.

Where the inventory plugs into a migration

A structured migration runs in five stages: scoping, pre-assessment, detailed assessment, execution, and aftercare. Scoping is a schema inventory and a complexity assessment. Pre-assessment categorises the estate, inspects metadata, and identifies the quick wins. The detailed assessment produces the technical analysis and the project plan. Execution does the transfer and the quality checks. Aftercare handles tuning and the issues that surface after go-live.

An accurate inventory changes the first two stages. A pre-assessment built on a live instance list sorts real workloads into real categories. The same exercise built on a stale export sorts guesses, and the quick wins it finds are often already retired.

The migration targets themselves are rarely the hard part. Worlber migration work covers Oracle, Microsoft SQL Server, EDB EPAS, MariaDB and MySQL, and MongoDB, with custom engagements for IBM DB2, Informix, Sybase, and Cassandra. The hard part is deciding what moves, in what order, and what stays behind.

Count first

Before you buy a migration tool, before you brief a partner, before you commit a deadline, count what you have. It is the cheapest step in the programme and the one that decides whether the rest of the plan survives contact with production.

If you want a second opinion on your PostgreSQL estate before you commit to a migration plan, talk to Worlber about a scoping assessment.

Scope your PostgreSQL estate with Worlber

Worlber runs PostgreSQL and legacy database migrations. Start with a scoping assessment of what you actually run, and plan against an inventory you can defend.

Talk to Worlber