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.
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.
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.
