Industrial Historian Migration: Separate Historical Imports from Live SiteWise Telemetry
A cloud path that accepts today's equipment readings may reject a historian archive from last month. Decide how historical records will enter the destination before sizing upload bandwidth or replaying a large export. Successful live collection does not establish that the same API accepts every historical timestamp or recomputes every derived result.
This article examines ordinary AWS IoT SiteWise time-series ingestion, not workspace session datasets. The API references were checked on October 19, 2026. The migration sequence is proposed engineering guidance; no archive was uploaded or measured.
Check the destination's time boundary first
The BatchPutAssetPropertyValue API accepts timestamp-quality-value data within an inclusive window from seven days in the past to ten minutes in the future. Values outside that window are rejected with a timestamp-range error. Sending an old archive faster cannot make its original timestamps eligible.
Do not replace measurement times with upload times to bypass the boundary. That would turn a historical record into a misleading account of current equipment behavior. Keep source time, its resolution, and its known interpretation with the exported data. Resolve an uncertain time-zone conversion before it becomes thousands of apparently valid destination points.
Partition the migration input by intended ingestion path. Recent observations may qualify for the live API, while older records require a supported historical path. Define a cutover boundary so simultaneous live collection and archive import do not accidentally treat the same interval as two unrelated sources.
Use historical import with its own prerequisites
CreateBulkImportJob defines an import from Amazon S3. For the ordinary time-series case discussed here, warm or cold storage must be enabled first. The workspace/session-dataset exception is outside this article's scope.
The import API also distinguishes historical storage from calculations: data older than seven days does not trigger computations or notifications. This matters when the proposed acceptance criterion is a historical efficiency chart or alarm record rather than merely stored raw measurements. List which outputs must exist after import and determine separately how they will be produced or validated.
The bulk-import configuration guide describes adaptive ingestion choices. Do not assume that setting an ingestion flag overrides every age and storage-tier condition. Match the selected configuration to the actual time range and the required processing behavior.
Define the overlap policy before replay
The live-write API documents replacement of an existing value when property, timestamp and quality match; a different quality is a different case. An archive replay can therefore change previously stored data rather than simply add missing records.
Consider a hypothetical historian export that overlaps a newly commissioned collector by one day. Decide which source is authoritative for that interval, whether corrected historical values should replace earlier values, and how the decision will be verified. Do not infer the answer from which upload finishes last.
Prepare a small representative subset containing an old interval, the cutover boundary, duplicate points, and intentionally invalid test data. Use an isolated target and inspect the resulting stored values and expected derived outputs. Keep the original archive intact while the mapping and ingestion behavior are under evaluation.
Verify job outcomes and the resulting history
A created bulk job is asynchronous. Its documented states include COMPLETED_WITH_FAILURES as well as COMPLETED and FAILED; the configured error-report location supports investigation. Treat an import that finished with failures as an incomplete reconciliation, not as a clean success.
Retain source files during validation rather than enabling automatic deletion merely to simplify storage cleanup. Record the job identity, source-file identity, expected time coverage, and unresolved errors. Compare representative destination queries with the original records, including units and the cutover interval.
The migration decision is complete when the team knows which path accepts each time range, what the destination will compute, and how overlapping values are handled. Only then does an upload-rate estimate describe a useful transfer rather than a fast stream of rejected or misleading history.
