New destination, same data. Down to the last row.
Switch databases or move to SAP without losing a single record. After every move, DataCore checks each table against the source and shows you anything that doesn't match.
Everything a DBA would check, done on every run.
A migration is finished when the destination provably matches the source — not when the last row is written. DataCore builds that proof into every copy.
The schema, not just the rows
Keys, unique constraints, indexes, identity columns and defaults come across.
Fidelity before you run
Every column labelled exact, converted, emulated, lossy or blocked.
Reconciled on every copy
Row counts, column sums and absolute sums, source against destination.
Compare any row
Source and destination side by side, differences only, or every row checked.
Reaches private networks
SSH tunnels with a private key, and errors that name the host that failed.
SAP-ready when SAP is the target
Cockpit templates read first; an acceptance gate checks every row.
Auditable enough for a change board.
A database copy runs on rules alone. On the SAP path, AI agents propose a mapping — but their output is never executed directly: a typed executor and an acceptance gate decide what reaches SAP.
# migration result · tally → postgresql
{ "status": "succeeded",
"tables_verified": "14 / 14",
"rows": 8770,
"foreign_keys": 14,
"lossy_columns": 0
}
Databases on both ends
One platform for the copy, the books and the ERP.
Replatform a database, move TallyPrime books into a relational schema, or prepare data for SAP S/4HANA — each with its own proof that the data arrived intact.
A DBA's migration, not a row dump.
The whole schema comes across: types with their length and precision, primary and unique keys, foreign keys, indexes, identity columns and defaults — rendered for the destination engine.
- — Every column labelled exact, converted, emulated, lossy or blocked before you run
- — Parents load before children; foreign keys are added after the rows, so the engine checks them
- — Row counts and column sums reconciled on every table
- Source
- PostgreSQL, MySQL, SQL Server, Oracle, SQLite
- Destination
- Any of the same five, same engine or cross-engine
- How it works
- Read the catalog, plan each column's type for the destination, create the tables, load parents before children, add constraints, reconcile.
- Proof
- PostgreSQL → MySQL → SQL Server → PostgreSQL: 8 tables each, row for row equal
Tally books, in a real relational schema.
Tally answers report requests, not SQL. DataCore copies the company's extraction into any of the five engines and turns Tally's own definitions into keys — so ledgers, groups and vouchers land as linked tables, not loose files.
- — Masters keyed on their GUID; parent links become foreign keys only where the data proves them
- — Amounts, rates and quantities become exact decimals, never floats
- — Reconciliation also sums absolute values — in double-entry books a plain sum is always zero
- Source
- TallyPrime, from its extraction
- Destination
- PostgreSQL, MySQL, SQL Server, Oracle, SQLite
- How it works
- Pick the extraction and the tables, review the plan, run. Keys come from Tally's own export definitions and are kept only where the data proves them.
- Proof
- 14 / 14 tables and 8,770 rows verified in all five engines; nothing lossy
Agents propose the map. SAP's rules decide what ships.
When SAP is the destination, DataCore reads the Migration Cockpit's own templates — custom fields included — and refuses to emit a file SAP would reject.
- — Every proposed field carries a reason; you approve the map
- — Technical keys minted correctly, never made up
- — Pushes through OData into a Migration Cockpit project you already have
- Source
- TallyPrime, or a SQL database
- Destination
- SAP S/4HANA, Migration Cockpit
- How it works
- Agents read the cockpit's own templates and propose a field-by-field map with a reason for each; you approve it, fill the gaps, and an acceptance gate checks every row before a file is emitted.
- Proof
- >85% of fields mapped and accepted on a gated catalog run
Six steps. Every one checked.
A database migration uses no AI: each step is a rule you can read, and a run that can't prove its result stops with a reason instead of guessing.
Questions teams ask before a migration
PostgreSQL, MySQL, SQL Server, Oracle and SQLite, in any direction — same engine or cross-engine. TallyPrime and MongoDB can be sources, and SAP S/4HANA is a destination through its Migration Cockpit. Other engines are added once they've been verified against real servers.
No. Reading the catalog, planning types, loading, adding constraints and reconciling are all rules. AI is used only on the SAP path, to propose a field mapping you then approve — and even there, its output is never executed directly.
The plan tells you before anything runs. Each column is labelled exact, converted (a different type that holds every value), emulated (for example an enum rebuilt as text with a CHECK), lossy, or blocked (left out, with the reason). Nothing lossy happens silently.
Every table is reconciled after the load: row counts, column sums and sums of absolute values, source against destination. A table is verified only when all of them match. The Compare tab then lets you check every row, view differences only, look up one record, or download the differences as CSV.
Yes — into any of the five SQL engines. DataCore copies the company's extracted data and turns Tally's own definitions into primary and foreign keys, keeping each key only where the data proves it. To copy current figures, refresh the extraction first.
Yes, through an SSH tunnel with a private key. If the SSH server can sign you in but can't reach the database, the error names the host and port that failed and how to fix it.
It feeds the Cockpit rather than replacing it. DataCore reads the Cockpit's templates — custom fields included — proposes the mapping, and an acceptance gate checks every row against SAP's rules before a file is produced. A build that isn't ready is refused, not partially emitted.