Import job history from previous system?

Question

We're evaluating FieldPulse as part of a broader platform consolidation. One requirement from our executive team is maintaining continuity of service history for active customer accounts. Our current system contains approximately 18,000 completed work orders across five years of operation. Are there established pathways to migrate this historical data into FieldPulse, or is the expectation that we begin with a clean slate? I am specifically interested in whether the API supports bulk work order creation with historical dates, or if a managed migration service is available through FieldPulse Professional Services.

Omar Hassan · Accepted Answer

Keiko — worth noting a few edge cases that can derail historical migrations, particularly around referential integrity. 1. Technician attribution : Historical work orders will need to map to user accounts in FieldPulse. If your previous system allowed free-text technician names (e.g., "Mike" vs. "Michael"), you'll need to normalize these before import, as the API enforces foreign key constraints on assigned technician IDs. 2. Status mapping : FieldPulse's work order state machine has specific terminal states (Completed, Cancelled, Invoiced). Legacy systems with custom status values (e.g., "Billed — awaiting payment") will need translation. The API rejects unrecognised enumeration values. 3. Attachment handling : If your 18,000 records include photos, PDFs, or signatures, the bulk API has a separate ingestion path for binary objects. Attempting to base64-encode large attachments into the work order payload will hit payload size limits (10MB per request). 4. Idempotency : For 18,000 records, you'll want to implement client-side idempotency keys. The API does not natively deduplicate on legacy IDs, so retry logic after partial failures can create duplicates. From a failure mode perspective, I recommend validating a representative sample (perhaps 1% stratified by year and job type) before committing to the full migration. This exposes schema mismatches early. It is worth noting that FieldPulse's audit log will attribute all imported records to the API key owner unless you specify created_by_user_id — worth considering for compliance traceability.

Daniel Cho (Staff) · Answer

Keiko, this is something we encounter frequently in my experience with mid-market implementations. What I typically recommend is a tiered approach rather than attempting a full historical import into active work order tables. In my experience, the API does support backdated work order creation — the created_at and completed_at timestamps can be specified during POST, though there are some guardrails. The system will flag orders with dates predating your FieldPulse account creation for audit purposes, which is generally fine but worth noting for compliance reporting. However, what I typically recommend is segmenting your migration strategy. For the full 18,000 records, consider whether all of this needs to live in the operational work order system versus a reference archive. In my experience, teams that import everything often find the noise-to-signal ratio problematic — technicians searching for relevant history get buried in outdated formats and incomplete records from legacy systems. What I typically recommend: import active warranties, unresolved callbacks, and customers with service agreements within the last 24 months as full work orders. For the remainder, the API supports a bulk customer import with custom fields that can hold legacy reference IDs, allowing you to link to external archives without polluting your operational dashboard. From a governance perspective, you'll want to validate timestamp formats — we've seen issues where legacy systems used non-standard datetime strings that the API accepted but rendered incorrectly in reporting. If you're interested, I can connect you with our Professional Services team for a scoping call on the managed migration path.