Production Management System Migration: Cutover Proof

The greatest risk in a production management system migration is not simply that data may fail to move. It is that the old and new systems may interpret the same sequence of events—sales order, production order, material issue, completion, inspection, shipment, and cancellation—differently. Even if every expected master and transaction record is converted, the factory is not in an equivalent state if an order on hold becomes confirmed or a retransmitted production result is posted twice.

Migration success should therefore be defined not by how many rows were moved, but by whether there is evidence that the same orders, inventory, and production results follow the same state transitions in both systems. This article is for leaders responsible for replacing ERP, production management, or MES systems at factories in Thailand. It brings data contracts, identifiers, units, time, reconciliation, parallel running, idempotent replay, cancellation, cutover, rollback, and business acceptance evidence into one assurance design. It is not a cloud-versus-on-premises product comparison; it is a practical guide to proving that a migration is fit to pass.

Production management system data migration is state reconstruction, not copying

A migration can look successful on screen when order numbers, item codes, quantities, and dates appear in the new system. Yet every production figure has a business context. An inventory quantity of 100 may mean available, awaiting inspection, on quality hold, supplied to a subcontractor, or already allocated. A production result of 10 may represent work in process, an operation completed, finished goods received, or a transaction awaiting cancellation. The next permitted action depends on that state.

The migration target is therefore not just a set of tables. It must include at least three things:

1. Identifiers and attributes: how orders, items, BOMs, operations, lots, equipment, storage locations, business partners, and operators are uniquely identified.
2. Current state: not only quantities, but business states such as approved, on hold, allocated, started, completed, and cancelled.
3. Events that created the state: when, by whom, from which device or interface, and for what reason the state changed.

ISA-95 is a family of standards that structures the boundary between manufacturing operations and enterprise business functions, together with information models, transactions, and identifier alias services. The official ISA overview of ISA-95, which includes the 2025 edition of Part 1, distinguishes Level 3 manufacturing operations from Level 4 functions such as ERP by activities and information rather than product names. A migration design should similarly avoid starting with “old table A maps to new table B.” It should start by establishing who owns each business fact and which state transition must be communicated to the other system.

Six reasons a migration can fail even when converted record counts match

The first reason is semantic mismatch. If “completed” in the old system means an operation has finished, while “completed” in the new system includes receipt into finished-goods inventory, a technically correct code conversion can still produce an inventory discrepancy.

The second is a difference in identifier granularity. An item-and-operation combination may be unique in the old system, while the new system may require plant, revision, and alternative routing as part of the key. Leading zeros, letter case, full-width and half-width characters, and site prefixes can also create collisions.

The third is unit conversion. “1 BOX = 20 PCS” may not always be true. If the factor varies by item, supplier, packaging configuration, or effective period, the quantity, unit, and basis of conversion must travel together. Purchasing, inventory, and costing may also apply different rounding rules.

The fourth is time. When a Thai factory’s local time, UTC, Japan head-office time, and an uncorrected PLC clock are mixed, the apparent order of the same events can reverse. ISO 8601-1:2019 defines date and time representations for information exchange, including UTC-based offsets. A migration must preserve not only display format, but also event time, receipt time, time zone or UTC offset, and information about the quality of the equipment clock.

The fifth is replay. If a terminal retransmits the same production result after a network interruption, a simple INSERT can create a duplicate posting. “The message was delivered” and “the business event was posted exactly once” are different assertions.

The sixth is cancellation and retrospective correction. Post-period-end production corrections, a repeated lot split, shipment cancellation, and recalculation of backflushing lose their reason and transaction chain if only the current balance is migrated. Matching the final balance for normal transactions is not enough.

Define the data contract before mapping fields

A data contract is more than an API specification. For every business object, it records the meaning, owner, identifier, state, permitted transitions, unit, time semantics, version, treatment of missing values, duplicate-detection rule, correction method, and retained evidence agreed by both the old-system and new-system teams. At minimum, build a register with the following columns.

Implementing ETL while the data contract still contains blanks allows developers to make implicit business decisions. Is an empty string an unset value or a valid blank? Should an unknown code be dropped, mapped to a temporary code, or stop processing? These are business decisions, not transformation details. Record the decision maker, deadline, and interim control before embedding the rule in code.

Normalize identifiers, units, and time without discarding source values

Even when creating a new enterprise-wide identifier, do not overwrite the legacy ID. Maintain a cross-reference containing source_system, source_id, target_id, valid_from, and valid_to, and make the migration batch, transformation version, and operator traceable. A shop-floor user who presents an old document number after cutover must still be able to find the corresponding transaction.

Do not bury the unit inside a number. Separate original quantity, original unit, converted quantity, base unit, factor, and rounding rule. For example, when converting 12.5 kg into pieces, do not blindly apply a fixed factor. Retain the effective item revision and whether an actual or theoretical conversion was used. When a discrepancy appears, this makes it possible to distinguish a migration error from a master-data error or a physical weighing variance.

For time, retain at least event_time and received_time. With offline equipment and terminals, arrival order is not necessarily event order. A result recorded late at night in Thailand may fall on the following date at a Japanese head office. Closing date, work date, shift date, and accounting date should be explicit business attributes rather than being inferred from the calendar date.

Prove equivalent business behavior with a state-transition ledger

The state-transition ledger is the core of reconciliation. Normalize events from both systems onto a shared business key and common event vocabulary, then compare them in sequence. For a production order, for example, the normal path might be RELEASED → STARTED → PARTIAL_COMPLETE → COMPLETED → CLOSED, with ON_HOLD, CANCELLED, REOPENED, and REVERSED as exception paths. Different internal terminology is acceptable if both systems can be projected onto an agreed comparison model.

The ledger should retain the business key, event ID, prior state, resulting state, quantity, unit, lot, event time, reason code, operator, source, processing result, and related event ID. A cancellation should not delete its original event; it should link to the event it offsets. This exposes cases in which current balances happen to match only because an incorrect history was later cancelled out.

GS1 EPCIS 2.0.1 is an official standard for creating and sharing visibility-event data across applications and enterprises. Even when a company does not adopt EPCIS itself, its event-oriented questions—what happened, when, where, and in what business context—provide a useful foundation for testing a migrated lot-traceability chain.

Make exception paths the center of golden scenarios

A golden scenario suite cannot consist of one representative document following the happy path. Define factory situations that create operational risk, including input, expected states, accounting and inventory impact, and retained evidence:

• Increase and decrease a sales-order quantity, split the production order, and ship only part of it.
• Issue substitute material, return the surplus, and trace both the original and substitute lots.
• Send the same production-result message three times and confirm that it produces only one business posting.
• Cancel a completion and verify that work in process, inventory, cost, and traceability reverse consistently.
• Prevent shipment of a quality-hold lot and permit allocation only after release.
• Deliver an older event late from an offline terminal without reversing sequence or posting twice.
• Produce the same item on both sides of a BOM revision date and confirm the correct revision and consumption.
• Test day-end, month-end, Thailand–Japan time differences, and an external site that observes daylight-saving time.
• Receive an ERP sales-order cancellation while MES processing is underway and confirm whether the result is rejection, hold, or compensating action.

OPC UA PubSub defines a publish-subscribe model for distributing data and events from device networks to IT and analytics or cloud observers. As OPC UA Part 14 v1.05.06 shows, distribution models, messages, and configuration matter. However, acknowledgement by a broker or an HTTP-success response from an API does not prove that a production order passed business validation and was posted correctly. Monitor transport, receipt, validation, business posting, and downstream processing as separate statuses.

Design parallel running as a comparison experiment, not duplicate entry

There are three common parallel-run topologies. The first is a shadow run: the old system remains authoritative, data is replicated to the new system, and the new system is used only for observation and comparison. It limits operational disruption but may not adequately test actions initiated in the new system or its exception procedures.

The second is double entry, in which users enter the same transaction in both systems. This can compare screens and operating procedures, but it imposes a heavy shop-floor workload. Differences in entry time or operator become discrepancies of their own. Define permitted time offsets and input responsibility instead of labeling every numerical difference as an error.

The third is phased ownership, in which business responsibility is divided by product family, line, operation, or site. This supports staged migration, but inventory, common master data, lot traceability, and costing cross those boundaries. The authoritative source must therefore be defined at the object level.

Dual writing may appear to be a safety measure, but it can fail partially: only the old write succeeds, only the new write succeeds, both succeed in a different order, or a cancellation fails on one side. If dual write is used, design the identity, result, replay behavior, compensating action, conflict resolution, and monitoring owner for every write. Dual write is not automatically safe. If ownership and conflict handling cannot be made explicit, a single input followed by event replication to a non-authoritative comparison system can create a clearer boundary.

A longer parallel period is not necessarily safer. Duplicate work causes fatigue, interim procedures become permanent, and unresolved discrepancies accumulate. Exit criteria should specify not merely the number of days, but how often representative scenarios must pass, the acceptable conditions for unresolved differences, and who approves the end of the parallel run.

Reconcile at three levels: technical counts, business state, and trace path

The first level is technical reconciliation: file counts, row counts, mandatory values, data types, lengths, referential integrity, hashes, and minimum and maximum dates. These checks are essential for quickly detecting loss or corruption, but they are only the entry point to acceptance.

The second level is business-state reconciliation. Compare open orders, incomplete production orders, work in process by operation, available inventory by lot, inventory on hold, allocations, completions, shipments, and pending cancellations using the same business keys and as-of time. Drill into detail, state, age, and owning site rather than stopping at aggregate totals. A total of 100 does not pass if lot A is short by 20 and lot B is over by 20.

The third level is trace-path reconciliation. Trace forward from a raw-material lot through its consumption order, operation results, finished lot, and consignee. Trace backward from a shipped lot to raw materials, equipment, and inspection results. Confirm that links remain intact across splits, merges, rework, and substitutions.

A diagnostic reconciliation metric can be expressed as:

terminal-state match rate = in-scope business keys with matching old/new terminal states ÷ total in-scope business keys × 100

This is a TOMAS TECH planning metric, not an industry-standard pass threshold. Define the denominator, exclusions, as-of time, tolerances, and severity rules first. A single discrepancy involving a critical quality hold or shipment cancellation may be sufficient to stop a Go/No-Go decision and must not be averaged away. Maintain a discrepancy ledger that records not only counts, but also cause classification, business impact, interim control, owner, due date, and retest result.

Engineer idempotent replay and auditable cancellation

Idempotency means that receiving the same intended request multiple times still produces only one business outcome. It does not mean merely ignoring an identical payload. The design must distinguish a sender that reissues an ID, events arriving out of order, a replay whose content has changed, and a repost after cancellation.

In practice, define an idempotency key using the source system, business object, event ID, event type, and version or sequence number. The receiver records states such as first processing completed, in progress, rejected, eligible for reprocessing, and cancelled. The retention period should not be shorter than the business period during which replay can occur. If the same key arrives with different content, do not silently overwrite it; quarantine and investigate it.

Cancellation is easier to trace when modeled as a compensating event that identifies the original transaction, not as a DELETE. Once downstream material issues, completions, shipments, or accounting integration have occurred, returning mechanically to the prior state may no longer be possible. Define how far automatic reversal is allowed and where an approved exception becomes necessary. If the old system has only one cancellation code while the new system distinguishes multiple reasons and states, do not invent meaning during migration. Use an explicit migrated value such as “legacy source—detailed reason unknown.”

Turn the system cutover plan into a time-ordered control sequence

Cutover is not a single data load into production. It is a controlled sequence that moves dependent systems, users, equipment, documents, labels, EDI, accounting, and warehouse processes at defined decision points. AWS Prescriptive Guidance on the cutover stage separates ingestion freeze, final backup, final synchronization, routing, and validation. It also explains that rollback after new transactions have been created is not just a matter of pointing connections back. Although written as general cloud migration guidance, the decomposition is useful for factory-system cutovers.

At minimum, the cutover runbook should specify these steps at minute or event level:

1. Start the change freeze and name the exception approver.
2. Stop old-system input or isolate the in-scope business area.
3. Inspect unsent queues, unprocessed documents, and pending jobs.
4. Take the final backup and identify the generation already proven restorable.
5. Perform incremental extraction, transformation, loading, and technical reconciliation.
6. Reconcile orders, inventory, production results, and trace paths at business level.
7. Verify terminals, labels, APIs, batch jobs, EDI, and reports end to end.
8. Define the input pack, authority, and deadline for the Go/No-Go meeting.
9. Open input in the new system and begin heightened monitoring.
10. Set the final decision time for rollback or fail-forward.
11. Define the conditions for moving the old system to read-only mode.
12. Track handover, next-shift confirmation, daily closing, and monthly closing.

Each line should include its entry condition, accountable owner, operator, checker, expected result, link to evidence, failure branch, and maximum duration. Name alternates and communication routes, not only primary staff. If approvers are split between a Thai site and a Japanese head office, include time-zone and interpretation needs in the decision lead time.

A rollback plan is more than restarting the old server

If no new transaction has been created in the new system, rollback by routing users back to the old system may be relatively straightforward. Once order changes, material issues, completions, or shipments have been recorded in the new system, however, the old system is stale. Simply redirecting screens would discard business facts created after go-live.

The rollback plan should therefore distinguish time windows:

• Before input opens: restore configuration and routing, then resume the old system.
• After input opens but before external commitment: determine whether new-system transactions can be extracted and applied through the old system’s approved procedures, or whether they must be cancelled and re-entered.
• After shipment, accounting, or customer integration: consider fail-forward—continuing controlled operations while correcting the fault—rather than assuming a simple rollback is possible.

A backup is not a rollback plan until the team has rehearsed restoration and recovery of post-cutover transactions. A backup alone does not prove that recovery time, recovery point, equipment configuration, interface credentials, terminal packages, label versions, and unsent queues can all be restored. The NIST SP 1339 OT Backup Quick Start Guide calls for OT backup to be integrated with change management, created regularly, tested, and reviewed through recovery exercises. Where the production system connects to manufacturing equipment, also account for the OT-specific performance, reliability, and safety concerns addressed in NIST SP 800-82 Rev. 3, and provide an environment and procedure in which restoration tests do not endanger production or safety.

A rollback rehearsal must test more than routing back when there is no new data. It must also test how transactions created in the new system are brought back to the old system or recreated as approved compensating transactions. The Go/No-Go authority should judge effects on shipping, inventory, cost, quality, and customer communication, not merely whether infrastructure can technically be restored.

Preserve business acceptance evidence as a project deliverable

A user’s “looks fine” during UAT cannot reproduce the conditions later. Acceptance evidence should link requirement ID, scenario, prerequisite data, actions, expected result, actual result, screen capture, log or reconciliation SQL, discrepancy, correction, retest, approver, timestamp, and version. Where Thai shop-floor terminology, Japanese head-office terminology, and English system fields coexist, maintain an approved, version-controlled glossary.

The evidence pack should include:

• The data contract and its change history
• Old-to-new ID cross-references and approval of unmapped, duplicate, and consolidated identifiers
• Migration-batch inputs, outputs, logs, hashes, and transformation version
• State-transition scenarios and results
• The discrepancy ledger and retest results
• Tests for replay, duplication, reversed order, cancellation, quarantine, and reprocessing
• Forward and backward trace results
• Performance, closing process, authorization, and audit-log results
• Cutover and rollback rehearsal records
• Operator training, attendance, comprehension checks, and support for users who have not yet demonstrated proficiency
• Go/No-Go minutes and signatures or approval records

This pack is not merely for audit. After go-live, it becomes the baseline for distinguishing a migration-data defect from an operating-process issue or a new customization requirement.

A 90-day PoC planning model for reducing uncertainty

The following 90-day structure is a TOMAS TECH planning model offered as a starting point. It is not a market average, a delivery guarantee, or a standard duration for an enterprise-wide migration. Scale it up or down according to the sites and lines in scope, data volume and quality, interface count, permissible downtime, regulation, language, and decision speed. Its purpose is not to finish production deployment in 90 days, but to reduce the uncertainty behind estimates and cutover decisions with evidence.

Days 1–30: Make contracts and risks visible

• Select one product family or line and explicitly state what is out of scope.
• Assign owners for orders, production orders, issues, results, inventory, inspection, and shipment.
• Profile legacy data and count missing values, duplicates, orphans, unused codes, and time inconsistencies.
• Define the data contract for IDs, units, time, versions, states, cancellation, and replay.
• Approve golden scenarios that emphasize exceptions over the happy path.
• Document cutover constraints, processes that cannot stop, external connections, statutory documents, and customer requirements.

Deliverables are the first contract version, a data-quality report, state-transition diagram, scenario list, risk register, and draft runbook.

Days 31–60: Migrate, replay, and explain discrepancies

• Convert representative master data and open transactions.
• Implement cross-references, transformation versions, and retention of original values.
• Feed the same events through both systems and build the state-transition ledger.
• Test duplicate replay, late arrival, reversed order, rejection, cancellation, and reposting.
• Reconcile at the technical, business-state, and trace-path levels, then classify causes.
• Simulate day-end, shift-end, and month-end boundaries.

Deliverables are a conversion prototype, reconciliation dashboard or report, discrepancy ledger, updated contract, and open-decision list.

Days 61–90: Rehearse cutover and recovery, then support the investment decision

• Run a role-based cutover rehearsal and record actual elapsed times.
• Rehearse rollback and fail-forward procedures that account for post-cutover data.
• Have shop-floor representatives execute golden scenarios and produce acceptance evidence.
• Organize unresolved differences by severity, workaround, owner, and due date.
• Re-estimate production waves, downtime, staffing, training, operational monitoring, and contingency days.
• Prepare the decision pack for Go, conditional Go, another PoC, or No-Go.

Passing the PoC does not mean “the demo ran.” At minimum, critical state transitions should be reproducible, discrepancy causes explainable, replay and cancellation controlled, cutover and recovery durations measured, and residual risks accepted by the appropriate decision makers.

RFP and vendor-evaluation questions

When outsourcing production management system data migration or an ERP migration, do not compare vendors solely on converted row counts and person-days. Ask every bidder the following questions under the same conditions:

1. Which keys, as-of time, and evidence will you use to judge state-transition equivalence?
2. How will you manage collisions, consolidation, splitting, retirement, and effective periods for old and new IDs?
3. How will you separate unit-conversion and rounding differences across inventory, purchasing, and costing?
4. How will you handle delayed offline-terminal events and duplicate replay?
5. Which compensating process applies when downstream transactions already exist after a cancellation?
6. During parallel running, which system is authoritative for each object?
7. Who approves each discrepancy, by when, and based on what evidence?
8. How many production cutover rehearsals will you run, and under which entry and exit conditions?
9. How will you demonstrate rollback or fail-forward after transactions have entered the new system?
10. In what format will you hand over migration tools, scripts, logs, cross-references, and acceptance evidence?

For a broader treatment of ongoing responsibilities and interfaces between ERP and production management, see ERP and Production Management System Integration. For the separate decision between a cloud and an on-premises target environment, see Cloud vs. On-Premises Production Management Systems. The focus here is the migration proof required whichever deployment model is selected.

Conclusion: prove the same business state, not just the same numbers

A production management system migration should not pass on converted row counts or similar-looking screens. Fix meaning through a data contract, preserve traceability across identifiers, units, and time, and reconcile whether the same events produce the same state transitions. Give parallel running explicit comparison objectives and exit criteria. Make replay idempotent, model cancellation as an auditable compensating action, control cutover through a time-ordered runbook, rehearse rollback or fail-forward with post-cutover data, and preserve business acceptance evidence.

Operational strength does not come from claiming that every difference can be eliminated. It comes from detecting material differences without omission and explaining their cause, effect, owner, due date, and interim control. Only when the same orders, inventory, and production results can be shown to reach equivalent business states in both systems does migration become more than a data copy—it becomes a defensible transfer of operations.

Even if migration scope and data quality are still being defined, the state transitions, reconciliation keys, and cutover and rollback assumptions can be reviewed together. If you are considering a production management system replacement or ERP migration for a factory in Thailand, contact TOMAS TECH. We can start with a 90-day evidence-PoC design before product selection, or with an independent review of an existing migration plan.

FAQ: Practical production management system migration

What should be decided first in production management system data migration?

Start with a data contract defining the authoritative source for each business object, its identifiers, state transitions, units, time semantics, versions, cancellation, replay, and acceptance evidence—not with a list of source tables. Map old and new fields only after that. Starting with field mapping makes it easy to bury unresolved meaning in transformation code.

Should ERP migration and production management system migration happen at the same time?

There is no universal answer. A simultaneous cutover may reduce temporary integrations, but it makes root-cause isolation and rollback more complex. A split cutover can limit scope, but it requires temporary interfaces and explicit authoritative-source management across the old and new systems. Choose migration waves according to the dependencies and downtime constraints among orders, items, production orders, inventory, results, and accounting.

Is parallel running mandatory?

No. Shadow running, double entry, and phased business ownership each have benefits and operating costs. A direct cutover may be viable when sufficient downtime is available and rehearsals and rollback controls are strong. If parallel running is used, define exit criteria in terms of passed scenarios, unresolved differences, and approvers—not duration alone.

What belongs in the Go/No-Go criteria for a system cutover plan?

Criteria should cover critical state-transition matches, unprocessed queues, reconciliation of inventory, open orders, and work in process, external interfaces, terminals and reports, severe defects, recovery capability, staffing, and the decision deadline. In addition to an overall match rate, define stop conditions for items such as quality holds and shipment cancellation where even one discrepancy may be unacceptable.

Is a backup enough for a rollback plan?

No. The team must rehearse recovery time, recovery point, configuration, terminals, interfaces, unsent queues, and the treatment of transactions created in the new system. It must decide how those transactions will be returned to the old system or handled through fail-forward. A backup whose restoration has not been tested is not proven usable.

How can duplicate posting caused by replay be prevented?

Use an idempotency key and processing ledger based on source, business key, event ID, event type, and version. Replaying the same event should return the same business outcome, while the same key with different content should be quarantined. Cancellation and reposting should retain their relationship to the original event and be processed as separate, valid events.

Will a 90-day PoC complete production go-live?

The 90-day model in this article does not guarantee a finished production deployment. It is a planning example for validating the data contract, conversion, state reconciliation, exception handling, cutover, and rollback within a controlled scope, thereby reducing uncertainty in the full plan and estimate. Its duration and scope must be adjusted to the size and risk of the migration.