Choosing what to put in the data core first: a migration plan
Moving everything at once is how migrations stall. Records point at other records, so the order matters more than the volume: people before RFIs, contracts before change orders, open work before history.
Five layers, in the order they depend on each other
An RFI points at a person and a company; a commitment points at a vendor and a cost code; a daily log's manpower points at both. Load each layer before the one above it, and pilot it on one live job before the rest.
- 01People and companiesEverything else points at them
- Directory: users and vendorsImport toolFirst scope in the import
- CRM contactsFile importCSV, up to 200 contacts
- 02The job and its codesEvery dollar needs an address
- ProjectsIn the appCreate, then import into it
- Cost codes and budget linesApp or APIEnter in the app, or by REST API
- ScheduleFile importP6 XER or Project XML
- 03ContractsWhat you can bill and what you owe
- Prime contractsImport tool
- Subcontracts and POsImport toolAs commitments
- Change orders and change eventsIn the appNo import today
- 04Open workWhat someone has to act on this week
- RFIs and submittalsImport tool
- Punch list and observationsImport tool
- 05HistoryRead rarely, needed when it matters
- Daily logsImport toolWeather, manpower, notes
- DocumentsImport toolFolders and files
- Accounting history: GL, AP, ARPlannedFull historical migration is unavailable; limited journal CSV import exists
Import tool (preview)File importIn the app or by REST APIIn the appPlanned
Dry run first, then one project
The import tool, under Migration for company admins, connects to one project management system's API today, plus a sample-data source you can practise on. Pick the source project and the os.construction project it goes into, and the scopes: directory, RFIs, submittals, punch list, observations, daily log (weather, manpower and notes), documents, prime contracts and commitments. They run in that order, directory first.
Dry run (count only, no writes) is the default: it reads the source and counts what would come over. Read the counts, fix what's skipped or failed at the source, then run it Live. Running it again updates what's already there instead of duplicating it, and if a run stops partway you can retry from the same source and keep what was committed.
The job page after a run shows the same columns: Fetched, Created, Updated, Skipped and Failed, per record type, with a run log. Illustrative counts.
Files, the API, and what's still planned
- Schedule: import a Primavera P6 XER or Microsoft Project XML file up to 2 MiB on each project, preview it, then commit. Each new file becomes a revision.
- CRM contacts: a CSV of up to 200 contacts and 50 columns, with every row reviewed and duplicates flagged before anything is created. CRM is in preview.
- Cost codes and budget lines: there's no file import. Enter them in the app, or script them through the REST API's cost code and budget line item endpoints.
- Drawings: uploaded one PDF at a time with their sheet details; there's no bulk set import.
- Change orders and change events: not imported. Bring open changes over by hand on the pilot job; leave closed ones in the old system's export.
Limited: accounting journal CSV import exists, but dimensional mapping and complete GL, AP, AR and job cost history migration are unavailable. Not today: a field-mapping screen or undo in the import tool, importing RFI or submittal logs from spreadsheets, and imports from more than one project management system. Tell us what you run before you plan a cutover around it.
Turn the order into dates
The migration planner takes what you run today, your fiscal year-end and busy season, and lays out a phased plan: prep and mapping, a pilot project, new jobs on the new system, accounting cutover, then history and retiring old tools. It runs in your browser and makes a link you can share.
Keep going
Keep exploring
Related across os.construction
- DocsKey concepts: one data coreWhy os.construction keeps project records, project financials and reporting on a single record model, and what that changes day to day.
- ExplainerWhy one data core: the same record everywhereSee how RFIs, field records, change orders, budget, pay apps and CRM link on one data core in os.construction, and why links beat copies and syncs.
- DocsWhat is os.constructionProject management, project Financials and company Accounting, with reporting on shared records.
- BlogWhy construction needs an operating system, not another appMost contractors don't have a software problem. They have a seams problem: the same number lives in five systems and none of them agree. The fix is a shared record, not another tool.
- ExplainerA day as a project managerOne PM's day on a sample project: the desktop, an RFI answer, submittals, the daily log, an OAC meeting, tasks and a change event, all on one record.
- GlossaryERP (Enterprise Resource Planning)Software that runs a company's core business processes, like accounting, payroll, purchasing and job cost, on one database.
Sample project included
Try this workflow on the sample project
Every trial workspace includes a sample project with sample data, so you can follow these steps in the app before touching a live job.
Want this on live job data?
The import tool is in preview and connects to one project management system today. Accounting journal CSV import is limited; full accounting history, budgets and change orders are not imported by the project tool.
14-day free trial. Pricing for paid plans isn't set yet. Talk to us. Already have an account? Sign in →
All figures are illustrative sample data, not a real project. Contract terms and state law decide how retainage, stored materials and change orders work on your job. Check both.