Migrate your data into STrOp

Moving systems shouldn't mean re-typing your company. The migration model is built around a simple split: what's alive moves; what's history becomes an archive. Master data loads first, in-flight jobs arrive at their real current state, and the old system's paper trail lands in the document registry where it stays searchable — no one re-enters eighteen months of anything.

Every importer lives under Import in the sidebar, takes a CSV, shows you a mapping step with auto-detected columns, and validates before anything is written. Two safety rails run underneath all of them:

• Nothing links silently. When a name in your file doesn't match an existing record — a GC spelled slightly differently, a cost code that isn't set up yet — the review step says so, suggests near-misses ("did you mean…"), and for companies offers to create minimal records on the spot. A row is never quietly imported with a dropped link.
• Every import can be undone — until it's built on. Each commit is recorded as a run (who, which file, what it created). An org admin can revert a run from the Import page while nothing references its rows; the moment real work depends on them — a timecard against an imported worker, a pay app on an imported job — revert refuses and names what's in the way.

1 · Master data, in dependency order

Work top to bottom; later importers link to earlier ones by name.

1. Companies — GCs, owners, vendors. Everything else links here.
2. Contacts — matched to companies by name.
3. Workers — classifications, labor agreements and default cost codes matched by name/code (set those up in Settings first, or import rates below). Leave SSNs and pay data out of the file entirely.
4. Products — your vendor catalog or materials price list; manufacturer and supplier link to companies.
5. Labor rates — CBA rate sheets, one row per classification per effective date. A new agreement name creates a minimal agreement record you finish in Settings.
6. Inventory — warehouse opening balances, after the product library exists.

2 · In-flight jobs — the part that used to be impossible

Historically, imports could only create pursuits. Now active work migrates as active work:

• Jobs — each row lands a project in execution with its contract identity: job number, contract value and number, retainage terms, dates.
• SOV baselines — one row per SOV line per job, with the line's scheduled value, billed-to-date, and retainage held. Lines must add up to the job's contract value to the cent — the importer refuses a sheet that doesn't reconcile, and tells you the delta.

When a job's baseline commits, STrOp seals it with one locked migration baseline pay application carrying your old system's last application number. That's the whole trick: your next pay app in STrOp starts at the next number, with the "previous application" columns already correct. The GC sees continuous G702 paperwork; nobody replays old billing.

Open change orders on a migrated job are entered through the normal Changes flow during onboarding — they're live negotiations, not history. Executed COs are already inside the contract value you imported.

3 · The archive — history without re-entry

Closed jobs, past pay applications, filed certified payroll, executed change orders: upload the PDFs to each job's Documents log (it takes a whole folder of files at once, typed and titled as you stage them). That satisfies record retention, keeps look-ups one search away — and because Ask your documents indexes the registry, "what did we bill through May on the Creekwood job?" gets answered from the archive without the old system's machine ever being turned on again.

What deliberately stays behind: the general ledger, AP/AR, payroll history. STrOp is the operational system of record, not the books — your accounting system keeps those.

4 · Coming from American Contractor (or another legacy system)?

Pick the American Contractor (.dbf export) kit on any importer's upload step. AC's xBase tables open in LibreOffice (or export via any dBASE tool) and save as CSV; the kit pre-maps the terse column names onto STrOp's fields and shows an extraction guide for which master tables feed which importer. Anything the starter map misses, assign by hand on the mapping step — then save the mapping as a template so the next file from the same system maps itself.

Migrating with us? Most teams run this with STrOp driving the first pass — the importers are the same ones you're free to use solo for a hundred companies on a quiet afternoon.