WorkflowShutdown, Turnaround & Outage

Turnaround Data Migration

Turnaround data migration that maps past job packs, take-offs and cost records to your new system’s template, with each cell tied to its source page and line.

Follow two batches from mapping to signature ↓
The problem

Turnaround data migration that nobody can trace back to a page

A new turnaround system wants past events in it, so planners can reuse job packs, estimates and lessons. That history sits in scanned job packs, schedule files, take-offs and cost records, written under tags and cost centers the plant has since changed, with dates written day first on some contractor forms and month first on others.

Clerks key it into the template, a trial load refuses rows days later with terse errors, and fixes go into the sheet with no record of why. When the client spot-checks a value, no one recorded the source page, so the check is the sheet against itself.

Built forData migration leadsTurnaround plannersClient data reviewersSystem consultantsInternal auditors

The Problem Today

Past turnarounds sit in scans, and no value in the migration sheet points back to its page.

41,900
hours to key every record by hand, at six minutes apiece our estimate
40%
of turnarounds overrun cost or schedule by more than 30% published

Matched by hand today

  • Old tags
  • Cost center
  • Dates
  • Source page
  • Errors found after the loadWrong tags and dates surface inside the new system
  • Recurring packs thrown awayA plain key check treats real history as a duplicate

The Solution

  1. A rule on each lineFields joined to the template; the agent asks when unsure
  2. A gate before any writeFixed checks hold what fails; a planner approves sourced fixes
  3. Lock, then a whole-batch trialThe system team loads a test copy before anyone samples
  4. A random sample, then signedThe client opens each cell at its line, the limit fixed at the draw

Built-in controls

  • Whoever prepares a batch cannot sign it
  • Your own template replaces the sample
  • Job packs load before what points at them

What You Get

The new system starts with its history in it, and any value can be defended to an auditor from its page.

2,250
people hours for the sample estate, against about 41,900 by hand our estimate
  • Counts that add upEach stage reconciled, down to rows accepted
  • Evidence for any batchRules, draw number, sampled cells and both signatures
  • Wear history keptA pack on the same tag, turnaround after turnaround
Two batches, one morning

Turnaround data migration for two batches of job packs, gate to signature

A refinery is moving six turnarounds of records into a new turnaround management system: 418,930 documents in 42 batches. This morning the newest job packs reach the gate, and the batch before them waits on the client’s last sampled record.

demoThe refinery, the people, the records and the counts are sample data.

  1. 0108:00

    One exchanger’s job pack, joined to the template with a rule on each line

    Data migration lead

    Fields read from the page sit on the left, the sample template’s work package fields on the right, and a rule chip on each line between them. 19 of 22 lines are signed. The mapping agent has three new proposals waiting, among them how to shorten long job titles at a word break, and it says what each would change before anyone approves.

  2. 0208:10

    A cost center open on the ERP list stays as read; a retired one moves on

    Data migration lead

    Clicking the cost center line opens its rule. A cost center that is still open in the ERP stays as written on the page. A retired one moves to its successor only when the ERP list names one, and otherwise the record is held. The rule shows its version, the records it touches, who approved it and who checked it.

  3. 0309:12

    The gate holds 472 records and writes nothing

    Data migration lead

    Ten fixed checks run over the newest job pack batch: 32,058 records. 31,586 would pass and 472 are held, and 0 are written. The largest group is 187 tags not in the live asset list, then 96 cost centers and 74 dates that cannot be told apart. The rework agent has already looked for a sourced fix on each held record.

  4. 04Rework

    An old tag, copied from an older pack, mapped by the retagging register

    Turnaround planner

    One held record opens beside its page. Its equipment tag is missing from the live asset list because the pack was copied from an older one and kept the old tag. A retagging register maps it to today’s tag, and the agent is 96% sure. The planner approves; the page itself never changes, and the fix waits for the migration lead’s second check.

  5. 05Lock and trial

    28,699 of 28,699 accepted on a test copy, in 47 minutes, then rolled back

    System implementation consultant

    The previous turnaround’s job packs cleared the gate with 0 held. The file was locked and fingerprinted, and the whole batch went through a trial load on a test copy of the target, then came back out. Only then did the sampling agent draw 315 records, with the draw number and a limit of 7 wrong fixed at the draw.

  6. 06Spot check

    Record 315 of 315, and its cost center lit at line 8 of page 1

    Client data reviewer

    The client’s reviewer is on the last sampled record: job pack JP-24-0417, the hydrocracker’s reactor effluent exchanger. She clicks the cost center and the scanned cover sheet opens with that line lit. The rule checked it is open on the ERP list, so it stays as read. The other cells already carry her marks, so she reads this one against the page and marks it right herself.

  7. 07Sign

    2 wrong of 315 means no more than 2.0% wrong, with 95% confidence

    Client data reviewer

    The sign box states what she is agreeing to: 315 records, each cell checked against its page, 2 wrong against a limit of 7, and 0 wrong critical cells. That bounds this batch at about 570 wrong records. The 2 wrong and the 41 like them go out as a correction batch through the gate, so the locked file never changes.

  8. 08Reconcile

    614,188 files in, 418,930 documents to migrate, each step counted

    Data migration lead

    The trail starts with the files that arrived, then subtracts what splitting, duplicates and retirements took out, ending at the documents that migrate. Beside it the target’s load log is held against the signed file, batch by batch, and a mismatch stays open until a person answers it. People’s time is shown as our estimate, with second checks and trial loads counted in.

  9. 09Board

    Oldest turnaround first, and job packs before what points at them

    Data migration lead

    The board shows all 42 batches by document type and turnaround: loaded, signed, in progress or not started, and who each one waits on. Because the oldest turnaround goes first, a recurring pack links back to one already loaded. Within a turnaround, job packs load before work orders, take-offs and cost records that carry their key.

472 held records, and 94 that need a person

Why the newest job pack batch was held at the gate, and how many the rework agent could back with a source.

Held becauseRecordsFix with a sourceNeeds a person
Tag not in the live asset list18714344
Cost center retired, no successor967125
Day and month cannot be told apart74740
Required field empty on the page614021
Code not on the template list38380
Dates outside the turnaround16124

demoSample data, from the working solution.

614,188 files received, and 418,930 documents left to migrate

The count trail the auditor reads, as it stands on the reconcile screen.

Files received1,284 held, 612,904 read614,188
Documents after splitting71,366 files held many documents847,312
Duplicates set aside286,540 exact and 94,118 near−380,658
Unique documents466,654
Retired to the archiveKept, not migrated−47,724
Documents that migrateAbout 1.3 million rows in the target418,930

demoSample data, from the working solution.

Around the batches

Held reasons, the migration file and the rules each batch loaded under

Six more screens the migration team, the client and auditors open between batches.

Why records are heldEach reason with how many records have a sourced fix and how many need a person, ready to preview in bulk.
The migration fileEvery row and field of a signed batch; any cell opens the page and line it came from.
The target templateFields, required marks, lengths and the rule that fills each. Your system team loads the real template here, and the agents show what changes.
Rules with versionsSixteen rules, each with two names and the records it touches. A loaded batch keeps the version it loaded under.
Audit trailSignatures, sample checks, approved fixes and exports by person, with reasons. Entries are fixed once written, and the evidence file is built from them.
The agentsSeven agents, what each is holding now, the line it cannot cross and the person it hands to.

demoSample data, from the working solution.

Who signs a batch, and why the preparer cannot

Rules, fixes and batches each take two names. Whoever prepared a batch cannot check or sign it.

Data migration lead
Sees
The canvas, the gate, the board and the count trail
Signs
Approves rules first and gives the second check on fixes
Turnaround planner
Sees
Each held record beside its page and the evidence for a fix
Signs
Approves or rejects fixes, or keeps a record held with a reason
System implementation consultant
Sees
The template, the rules and the whole-batch trial load
Signs
Second check on rules, and the trial load on a test copy
Client data reviewer
Sees
Every cell of each sampled record against its page
Signs
The batch, or sends it back
Internal auditor
Sees
Any batch’s evidence file, and the same sample redrawn from its number
Signs
No decision; exports evidence
The agents

Seven agents map, check and count, and none writes to the target

Each stops at a person before anything changes.

Template reader

Reads the target template’s objects, fields, required marks, lengths and code lists.

  • Never guesses a field the template does not state
Mapping agent

Proposes a rule for each line from a field read to a template field, and cites examples.

  • Never signs a rule
  • Never changes a signed one
Tag and code resolver

Turns old tags, cost centers, disciplines and material numbers into today’s values from the crosswalks.

  • Never invents a code; no match means held
Gate checker

Runs ten fixed checks over a whole batch.

  • Never writes to the target
  • Never waves a record through
Rework agent

Looks for a sourced fix for each held record: another page, a change record or sibling packs.

  • Never changes a source page
  • Never applies its own fix
Sampling agent

Draws the random sample from a locked file, keeps the draw number, and looks for the same pattern when a cell is wrong.

  • Never picks records
  • Never marks a cell right
Reconciliation agent

Compares the signed file with the target’s load log: counts, totals and refused lines.

  • Never closes a mismatch by itself

What migration leads ask about turnaround data migration

What is turnaround data migration?

Turnaround data migration moves past turnaround records, such as job packs, take-offs, schedule files and cost records, into a new turnaround management system. Here agents map each field to the target template, a gate holds what fails, the client checks a random sample against the pages, and the output is a signed file for the system team to load.

Does it load data into our turnaround management system?

No. It hands over a validated, signed file prepared for integration. The load stays with your system’s own import tool, and the load log comes back to be reconciled against the file.

How does the sample prove a batch is right?

The sample is drawn at random from a locked file after a whole-batch trial load, with the draw number and limit fixed at the draw. A record is right only when every cell matches its page. The signature states the upper bound on the wrong rate, so anyone can redraw the same sample and check it.

What happens to old tags and retired cost centers?

The resolver maps them through the crosswalks, such as a retagging register or the ERP list of retired cost centers. When there is no match, the record is held, and a planner settles it beside the page with a second person checking.

Can it handle legacy maintenance data migration from scanned files?

Yes, after the records steps before it have split, sorted and checked the scans. One scanned file often holds many job packs, so each cell cites the page and line it came from rather than the file alone.

Do we need to use your template?

No. The template on these screens is a sample. Your system team loads the real one, and the agents show what changes before any batch moves.

Why are recurring job packs kept?

The same pack number on a later turnaround is the equipment’s wear history, not a duplicate. The key joins the pack and the turnaround, so each one migrates.

Bring one batch of old job packs
and your system’s template.

We’ll map it with you and open any cell at its page before anything reaches the new system.