Technical insights

WellView data migration: what to validate before go-live

A practical checklist for protecting well identity, record relationships, reporting dates and operational calculations during database migration.

WellViewData migrationSnowflake

1. Agree on what must match

Before migrating records, define the well and job scope, target fields, expected report outputs and reconciliation rules. Agree whether inactive, archived and historical records are included.

2. Validate parent-child relationships

Well data is relational. A well may contain multiple jobs, daily reports, rigs, cost records and operational logs. The migration should preserve keys, foreign-key relationships and the meaning of each child record.

3. Review date and time logic

Reporting date, entry date and operational start/end timestamps are not interchangeable. Test time-zone handling, operating-day boundaries and asset-specific daily report conventions.

4. Reconcile at multiple levels

  • Source and target counts for wells, jobs and daily reports.
  • Unique identifiers and duplicate records.
  • Totals by well, job, rig and operating date.
  • Cost, duration and performance calculations used by existing reports.
  • Exceptions, null values and unexpected changes in classifications.

5. Validate real business reports

Matching row counts alone does not prove a successful migration. Compare known operational reports, dashboards and selected high-risk wells against the original system.

6. Document assumptions and exceptions

Keep a mapping register, exception log, test evidence and sign-off criteria. This creates traceability for future support and subsequent system changes.

The checks must be adapted to the customer's approved WellView configuration and reporting definitions.

  • Well identity: compare distinct well IDs independently of names, which may be duplicated or changed.
  • Jobs and reports: reconcile counts by job type, job ID and operational reporting date; investigate orphaned or duplicated child rows.
  • Time: verify units, rounded durations, time zones and any asset-specific operating-day boundary.
  • Costs: compare report-level totals and avoid double counting when joining detail records from more than one child table.
  • Cutover: identify dashboards and scheduled extracts that still use the legacy database.

Examples of checks worth making explicit

This is general technical guidance, not a validated procedure for a particular WellView version or customer installation. Test against the relevant system and approved data model.

Explore JUIA's migration and integration services →

Let’s talk

Book a Consultation

Discuss your WellView, WellView Allez, OpenWells, migration, reporting or AI requirements with JUIA.

Get in touch →