Data Porting

Last updated: June 20, 2026

Data porting imports and exports your organisation's data in spreadsheets, entity by entity, so you can load opening data, migrate from another system, or bulk-edit and re-import. It is the bulk-data doorway into and out of Cloudby, and it is built to be safe as well as powerful.

What you will learn
  • Which data can be ported
  • The import pipeline: validate, stage, apply
  • How an import is tracked
  • When to reach for porting
XLSX fileone per entityValidatecatch errorsStage + applydata landsImport validates and stages before applying, so bad rows are caught first
Import runs validate then stage then apply, so errors surface before data lands simplified mockup

How it is structured

Modular, per entity area

Porting is modular: each data area, Sales, Purchase, Accounting, Customer, Vendor, Inventory, HR, Organisation and Service, is handled by its own porting module over a shared base. So you port customers with the customer module, inventory with the inventory module, each understanding the shape of its own data, rather than through one undifferentiated dump.

Spreadsheets in, spreadsheets out

The format is XLSX spreadsheets. Export pulls an entity's data out to a spreadsheet for editing or backup; import reads a filled spreadsheet back in. Working in a familiar spreadsheet is what makes bulk preparation and correction practical.

How it behaves

Validate, then stage, then apply

An import does not write blindly. It validates the spreadsheet, then stages the data, and only then applies it, so bad rows are caught and surfaced before anything lands in your live data. Each import is a tracked record carrying its purpose, the data file, its options, a status and the validation result, with who completed it and when, so a migration is auditable rather than a one-off action with no trail.

Handle with care. Importing writes real data into your organisation. Always read the validation result before applying, prepare against the exported template so columns line up, and where you can, rehearse a large migration on a sandbox first. The validate-and-stage step is your safety net, use it.

Worked example

Migrating from a legacy system, you export the customer template to see the exact columns, fill it from the old data, and import it. Validation flags a handful of rows with bad currency codes; you correct them and re-import, and your customer master loads cleanly, with the import record standing as the audit of what was brought in.

Edge cases and good practice

  • Export the template first so your spreadsheet matches the expected columns exactly.
  • Read the validation result before applying; it is there to catch errors cheaply.
  • Port entity by entity, in dependency order (masters before the documents that reference them).
  • Rehearse big migrations on a sandbox where possible.

Related