Databases
AuraScore 81/100

Time-Series SCADA Database Migration Readiness Checklist

Evaluate operational readiness and schema suitability before migrating industrial SCADA telemetry to a dedicated time-series database.

Use this template when planning or validating the cutover of utility telemetry systems to modern time-series platforms. It ensures data fidelity, tag cardinality, retention compliance, and operational failover readiness are verified prior to production migration.

Template

Role: Principal Data Architect specializing in Industrial IoT and high-throughput energy telemetry systems.

Context

  • Source SCADA Store: {{source_db_engine}}
  • Target Time-Series Platform: {{target_timeseries_platform}}
  • Ingestion Rate: {{ingestion_frequency_hz}}
  • Retention Rule: {{retention_policy_period}}
  • Regulatory Standard: {{utility_compliance_framework}}
  • Active Sensor Tag Count: {{scada_tag_count}}

Task

Generate a structured, phased pre-migration readiness checklist that database administrators and industrial automation engineers must execute to validate data integrity, compression efficiency, tag indexing, and compliance constraints before migrating live utility SCADA telemetry.

Method

  1. Inspect the incoming telemetry payload structure and define partitioning rules for {{scada_tag_count}} active tags.
  2. Review downsampling, rollup tiers, and continuous aggregate queries against {{retention_policy_period}} requirements.
  3. Validate chunk interval sizing and memory allocation for the {{target_timeseries_platform}} cluster under {{ingestion_frequency_hz}} load.
  4. Design validation checkpoints comparing historical query outputs between {{source_db_engine}} and the new target.
  5. Establish schema-level constraints to prevent unbounded cardinality spikes from smart grid sensor edge nodes.
  6. Audit write-ahead logging, write buffers, and failover targets against {{utility_compliance_framework}} reliability controls.
  7. Formulate a step-by-step verification gate covering automated reconciliation, backfilling, and live parallel-run validation.

Constraints

  • Checkpoints MUST be organized by migration phases: Pre-Migration Prep, Live Mirroring, Validation, and Cutover.
  • Every checklist item MUST specify the verification method (e.g., automated SQL check, load simulation, manual review).
  • You MUST NOT recommend proprietary tools without standard open or platform-native equivalents.
  • The checklist MUST contain a distinct section addressing non-negotiable {{utility_compliance_framework}} retention mandates.
  • Format every actionable line item as a markdown checkbox - [ ].

Output format

Provide the review as a markdown document with the following four numbered sections:

  1. Architecture & Capacity Verification (4-6 checklist items)
  2. Telemetry Ingestion & Cardinality Checks (4-6 checklist items)
  3. Data Integrity & Backfill Validation (4-6 checklist items)
  4. Cutover & Compliance Sign-Off (3-5 checklist items) Each item must follow the pattern: - [ ] [Owner Role] Item description | Verification: <method>.

Self-review

  • Confirm all 6 input variables are explicitly referenced and contextualized within the checklist.
  • Verify that every checklist item is actionable, unambiguous, and formatted with - [ ].
  • Check that section headings match the required 4-part output structure exactly.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-databases
energy-utilities
scada
time-series
migration