About Your Data

We import your existing (“legacy”) data from your current systems as part of an Onboarding Engagement, scoped against your chosen Tx-Rails integration mode (Hash-only / CDC observation / Gateway-mediated / SDK atomic dual-write — see Four integration modes). The data-migration cost is fixed per engagement and rolled into the platform subscription. Tx-Rails is then deployed under your existing application stack — no front-end replacement, no rip-and-replace. When migration is complete and the deployment has passed pilot acceptance, you “go live” — commencing your “Onboard Live Now” status — and platform fees apply per the per-pyramid + per-federation tier schedule (see the relevant industry pricing sheet).

You will need to have cleansed your own data of duplicates, mis-spelled “non-duplicate” duplicates, incorrect items of various types, and any known extant errors, before exporting your essential data including closing and opening balances (typically as a set of CSV, JSON, or Parquet files; we accept whatever your existing systems can export). This is your chance to start fresh and get it right.

Tx-Rails data migration onboarding flow

In some cases Tx-Rails databases are deployed per installation — each customer organisation (or federation) gets its own BFT-replicated database stack, isolated by infrastructure rather than by a row-level tenant key. There is no shared multi-tenant database where your data co-resides with another customer’s. In other cases (eg Social Housing) organisations do share databases, differentiated by the their entnum. Records are tagged with a Member-or-Class identifier (the memberOrClassId field of the 23-field metadata schema) and an entnum identifier, which is your stamp of ownership on every transaction. Deployment location is customer-elected at engagement time — common choices include ITOTCCA-operated managed nodes in London / Sydney, your own on-premise infrastructure, or your preferred cloud provider (GCP, AWS, Azure, OVH, sovereign-cloud equivalents). Data sovereignty is preserved — only 24-block Merkle slab roots are anchored to the public Hedera distributed ledger for cross-jurisdictional tamper-evidence.

Every customer retains the right to reverse their decision to join us at any time. Because Tx-Rails operates as an underlay beneath your existing application stack — not as a replacement — your primary system-of-record never stops being yours. On exit we provide a full export of every transaction Tx-Rails recorded on your behalf, in the form in which it was originally received (typically a set of CSV / JSON / Parquet files plus any binary attachments), so the data can be re-imported into your preferred database system. If your old system cannot ingest the export directly, we provide a generic database-dump format of your choosing (SQL DDL+DML, NDJSON, Avro, or a PostgreSQL pg_dump). For customers running in Modes A or B the export is a one-step process — your data never left your primary system in the first place; we simply hand back the cryptographic audit trail for archival.

Tx-Rails reversible data conversion

Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.