database migration
Oracle, DB2 and SQL Server to PostgreSQL in 30 days, every row checked
The licence renewal is on the calendar again, and the stored procedures nobody wants to touch are the only reason you still pay it. Engineers with 25+ years in production move your schema, logic and data to PostgreSQL in 30 days.
Within 48 hours an engineer sends a fixed price, a cutover date and the list of objects we port.
Oracle, DB2 or Sybase, business rules buried in packages, and a renewal date everyone dreads.
- Oraclelicence per core
- PL/SQL packagesbusiness logic
- DB linkscross-database
- nightly ETLhand-kept
30 days, cutover over live replication with zero downtime
Logic in PL/pgSQL or tested Go services, every row reconciled, the licence cancelled.
- PostgreSQLno licence
- servicesGo · logic out of the DB
- replicationno downtime
- reconciliationrow by row
From licence to PostgreSQL in 30 days
- 01days 1–4
Inventory the database
Tables, sequences, triggers, packages, jobs, database links and every query your applications send. The platform reads all of it in one pass, and the price comes from what actually runs.
- 02days 3–14
Port schema and logic
Types mapped, constraints kept, PL/SQL and T-SQL ported to PL/pgSQL or lifted into Go services with tests. Your DBA and our engineer choose the target for each package.
- 03days 10–24
Copy and reconcile
A full load, then change data capture keeps PostgreSQL current while production runs. Checksums compare every table row by row, and your queries replay on both engines until the results match.
- 04days 25–30
Cut over
Replication catches up, applications move their connection string, and the old engine stays warm as a rollback target until you sign. Then the licence goes.
Who does what on your database
Reading schema, packages and query logs
Platform
Thousands of objects parsed in one pass, including the ones generated by a tool nobody has run since 2011.
Type and dialect mapping
Platform
NUMBER, DATE, CONNECT BY, MERGE, sequences and old outer-join syntax translated, then reviewed as a pull request.
Where each stored procedure ends up
Engineer
Some logic belongs next to the data in PL/pgSQL, some in a Go service with tests. A senior engineer decides per package.
Row-by-row reconciliation
Both
Checksums and counts are ours. Which historical rows were already wrong is a call your side signs.
Query performance on PostgreSQL
Engineer
Execution plans compared query by query and indexes rebuilt for the new planner before a single user connects.
Cutover and rollback
Both
Replication, the switch and the rollback window run on a date written into the contract.
Translating the schema is the fast part. Every ported object goes through a senior engineer before it touches production data.
Why this team gets your database
Our engineers have been running production systems for more than 25 years, and they have ported PL/SQL packages, DB2 stored procedures, Sybase T-SQL, Informix 4GL and Access macros. They know where NULL handling, date arithmetic and implicit casts change an answer between engines, and they find it before your auditors do. For moving the database that pays your salaries, they are the best people you can hire.
Fixed price per phase and the cutover date in the contract. A phase is accepted when the reconciliation report balances to the row, and every script and service is yours from the first commit.
What DBAs and CTOs ask us
We have thousands of PL/SQL packages. Can PostgreSQL run all that?
Most of it ports to PL/pgSQL directly, and the platform does that translation in bulk. Packages that carry business rules, like pricing or settlement, usually move into Go services with tests, where your developers can work on them. You see the split per package before we start. Get a quote and the list arrives with the price.
We cannot take downtime. How does the switch work?
A full copy first, then change data capture streams every write from the old engine into PostgreSQL while production runs. On cutover day replication catches up, applications move their connection, and the old database stays ready as a rollback target. Your users see an ordinary day. Pick the date and we write it into the contract.
How do we know no data was lost?
Every table is compared row by row with checksums, and your own queries replay against both engines until the results match. You get a reconciliation report per table and sign it before cutover. Rows that never balanced in the old system are flagged by key. Get a quote and reconciliation is in the price.
Will PostgreSQL keep up with our heaviest queries?
Your heaviest queries are timed on both engines before cutover, and anything slower is tuned until it is at least as fast, with indexes, partitioning and rewritten SQL where the planner needs it. You go live on numbers you have already seen. Get a quote this week and those numbers are on your desk inside the 30 days.
What about the applications that talk to the database directly?
The platform reads every query they send, from ORM calls to SQL glued together with strings in a 2004 report. Queries that need changes get rewritten and retested against PostgreSQL through the same harness. Access and FoxPro front ends we rebuild in TypeScript if you want them gone too. Put them in the request and they are in the price.
Your last licence renewal
Share the engine, the size and the renewal date today. A fixed price and a cutover date reach you within 48 hours, and 30 days after you approve, PostgreSQL serves production and the licence is cancelled.
Rough object counts are enough. An engineer reads the request and answers with a written price.