Migrate your Built data

The core object in Built representing individual workers. Each Employee record includes name fields, title, employment type, start date, and reporting relationship. We map Employee records 1:1 into the destination HRMS and preserve the Manager assignment as a foreign-key reference so reporting hierarchies render correctly at the destination.

Department records represent organizational units within Built. They map cleanly to the equivalent concept in most destination HRMS platforms. We preserve the department name, code if present, and head-of-department assignment during migration.

Location records represent office sites or remote-work designations. Field naming and hierarchy vary significantly between HRMS platforms. We review the source location schema before migration and apply a value-mapping pass to align with the destination's location taxonomy.

Job title is stored as a field on the Employee record in Built. Titles migrate as free-text string fields which is standard across most HRMS destinations. No transformation required unless the destination enforces a controlled job-title vocabulary.

Built tracks whether an employee is full-time, part-time, contractor, or temporary. These values map cleanly in most cases, but we check the destination's enumeration values since some HRMS platforms use different labels (e.g., 'Regular' vs 'Permanent') that require a lookup-table translation.

The reporting relationship is stored as a link from Employee to another Employee record. We resolve these links during migration by performing a two-pass import: first load all Employee records, then update the manager reference field with the destination IDs. Circular reference detection is applied to prevent impossible reporting loops.

Organizations can define custom properties on Employee records in Built. Custom field names, data types, and picklist values vary by org. We extract the full custom field schema at the start of migration and apply a field-level mapping pass to align with the destination's custom property names and types.

Built stores documents and files against Employee profiles. Attachments are not included in standard API exports and require a separate file-level export process. We can export attachments as individual files and store them in a parallel folder structure keyed by employee ID, but they cannot be re-linked automatically inside most destination HRMS without custom integration work.

The visual org chart is a rendering of underlying employee hierarchy data, not a separate data object. When migrating out of Built, we extract the underlying Employee and relationship data; the visual layout itself cannot be transferred and must be regenerated at the destination from the migrated hierarchy data.