Three days before cutover, the migration lead at a mid-sized New Zealand distributor is juggling two vendors, a warehouse still dependent on a 2008 ERP, and finance staff double-keying transactions into a new SaaS platform. A Sev-2 incident arrives just as the team discovers an undocumented batch job that sends stock data to a logistics partner.
That's legacy system migration in 2026. The difficult work isn't moving files between environments. It's keeping customers served while hybrid platforms, compliance obligations, brittle interfaces, vendor contracts and real operating habits change underneath the business.
A disciplined programme starts with discovery, then makes an explicit strategy choice between lift-and-shift, replatforming, rewriting or a hybrid combination. It treats data and integration as separate delivery disciplines, joins security and cutover evidence into one approval pack, and gives users practical support rather than a generic training email. After go-live, the programme continues through a structured 90-day rhythm of hypercare, optimisation and controlled decommissioning.
New Zealand public-sector programmes show why this matters. Inland Revenue identified more than 400 applications for decommissioning, with the final few switched off on 31 March 2022 after more than 5 years of transformation work. That isn't a single cutover. It's a managed sequence of shutdowns, data decisions, operational transitions and governance gates. New Zealand's legacy system guidance provides useful context for the scale and discipline involved.
What a Legacy Migration Looks Like in 2026
A migration rarely ends with one clean weekend. A business may move its core workload to the cloud while keeping a warehouse interface, reporting database, identity service and several partner connections in operation. Some applications will be replaced. Others will sit behind APIs or middleware, while a few remain until a later release.
That is a delivery problem as much as an architecture decision. Each unresolved dependency can become a cutover incident, and each late decision creates another temporary control for the team to operate.
Start with the service, not the server
Begin by identifying the business services that must stay available. Order fulfilment, payroll, claims processing, property transactions and customer support are better planning units than server names or application inventories. From each service, map the applications, data stores, interfaces, controls and human workarounds that keep it running.
A technically old platform may still perform a dependable business function. Replacing it without understanding the surrounding process can remove an undocumented rule that staff use every day. That risk is common in public-sector delivery, where service continuity and auditability matter as much as the target architecture.
Teams working with older customer or messaging channels should record the interfaces they still rely on. Where the estate includes older channel patterns, browse older channel integrations while building the interface inventory. Use the reference to improve discovery, not to force a design chosen before the evidence is available.
Treat migration as a sequence of gates
A practical programme has six connected stages:
- Discovery: Establish the estate, dependencies, data condition and service impact.
- Strategy selection: Choose lift-and-shift, replatforming, rewriting or a hybrid path for each workload.
- Data and integration delivery: Prove mappings, reconciliation and interface behaviour before production.
- Security and cutover: Produce approval evidence, rehearse the runbook and define rollback authority.
- Change and adoption: Prepare role-based training, communications and hypercare coverage.
- Post-go-live optimisation: Stabilise the service, remove temporary bridges and retire obsolete components.
Each stage needs a go or no-go decision. The executive sponsor should know the required evidence, the person authorised to stop the release and the conditions that trigger rollback. This structure fits the operational reality of NZ and Australian programmes: work moves through controlled gates, owners are visible, and decisions can be traced when service impacts or audit questions arise.
A phased programme can reduce failure domains without slowing delivery by default. It gives teams earlier feedback before the highest-risk workloads move and lets the work-management platform hold actions, dependencies, approvals and cutover tasks in one operating view.
Practical rule: If the team cannot explain which customer or staff service depends on a component, that component is not ready to migrate.
The strategy still requires trade-offs. Lift-and-shift reduces immediate change but preserves technical constraints. Replatforming offers a middle path, while rewriting can deliver greater capability uplift with more uncertainty. Choose by workload, not by programme fashion. A hybrid strategy is often the clearest representation of the estate.
Assessment and Discovery Before You Touch a Single Server
Assessment is the make-or-break stage because migration plans fail when teams estimate technology instead of operational complexity. A server list won't reveal a spreadsheet uploaded by one administrator, an FTP drop consumed by a partner or a scheduled job that has no owner. Discovery has to expose the estate people operate, including the workarounds they rarely document.
New Zealand public-sector guidance supports a phased approach that defines current and target architecture, identifies dependent business services, prioritises candidates by risk and value, and preserves a fallback path until cutover is proven. That principle should be applied before scope is signed, not added to the plan after the first failed test.
Build four artefacts that force clarity
The system inventory should capture servers, applications, databases, operating systems, owners, support arrangements, environments and licensing constraints. Include scheduled tasks, file shares, manual exports and vendor-managed components. A discovery tool such as Device42 transformation migration can support infrastructure visibility, but the delivery team still needs interviews with operators and business owners.
The dependency map should show direction, timing and failure behaviour. Record APIs, batch files, FTP transfers, message queues, direct database reads and shared-service connections. Mark dependencies that are synchronous, because those are more likely to affect transaction response, and identify interfaces that fail without raising an alert.
The data readiness scorecard needs more than a volume estimate. Profile nulls, duplicates, orphan records, invalid codes, referential integrity and personally identifiable information locations. Assign an owner to each cleansing decision. A data set isn't ready because it can be extracted. It's ready when the business accepts what will be transformed, retained, rejected or archived.
The business impact assessment translates technical exposure into service language. Link each component to the processes, customer commitments, regulatory controls and recovery requirements it supports. Shared-service integrations involving agencies such as the Department of Internal Affairs or Statistics NZ can narrow cutover windows and require coordination beyond the immediate project team.
Assign owners before scope approval
Use a compact discovery checklist with accountable names:
- Architecture owner: Current-state and target-state diagrams.
- Application owner: Functional boundaries, known defects and operational constraints.
- Integration lead: Interface catalogue, dependency heatmap and partner contacts.
- Data lead: Field mappings, profiling results and cleansing decisions.
- Security lead: Identity, access, logging and compliance requirements.
- Business service owner: Impact assessment, acceptance criteria and fallback approval.
- Delivery lead: RAID log, decision register and scope baseline.
Don't approve a migration wave until these artefacts have named owners, review dates and unresolved risks visible to the steering group. Discovery isn't paperwork around the project. It is the evidence that tells you whether the project has a manageable boundary.
Choosing Your Migration Strategy
Choose the strategy per workload, not for the estate as a whole. A stable application with urgent hosting risk may deserve a lift-and-shift. A platform with a tolerable codebase but an unsupported database may suit replatforming. A product whose business rules no longer fit the organisation may justify a rewrite, but only when the business can fund the uncertainty and supply the skills.
| Criterion | Lift-and-Shift | Replatform | Rewrite |
|---|---|---|---|
| Business risk | Lower application change risk, but operational constraints remain | Moderate change risk with controlled platform improvements | Highest change risk because behaviour is rebuilt |
| Elapsed time | Usually the quickest route to a new hosting environment | Longer, due to runtime or database changes | Longest, with discovery and product design continuing through delivery |
| Three-year total cost of ownership | May retain higher support and management costs | Can improve manageability without replacing all code | May reduce structural debt, but requires substantial delivery investment |
| Capability uplift | Limited | Moderate | Highest potential uplift |
| Regulatory exposure | Existing control weaknesses may remain | Controls can be redesigned around the target platform | New controls and evidence must be proven across the rebuilt service |
| Required skills | Existing application skills remain important | Platform, database and integration expertise become critical | Product, engineering, architecture, testing and domain skills are all required |
Lift-and-shift moves the workload with minimal functional change. It can buy time, reduce pressure on physical infrastructure and create a safer platform boundary, but it won't automatically fix poor interfaces or obsolete operating practices. Replatforming changes the runtime, database engine, packaging or hosting model while preserving most application behaviour. Rewriting replaces the application around modern services, APIs and domain boundaries, which creates opportunity but also a larger testing and adoption burden.
Use a weighted decision matrix
Score each option against agreed criteria, then make the weights visible. Business continuity and regulatory exposure may outweigh capability uplift for a critical service. A non-critical internal application may justify more change if the organisation needs to remove specialist support dependencies.
Consider infrastructure-as-code where it improves repeatability and auditability. A practical reference for the best use cases for Terraform can help the team distinguish reusable environment automation from code added merely because it is fashionable. Cloud delivery should also align with the organisation's cloud services capability, including operational ownership after the migration.
A realistic hybrid example
Take a 20-year-old claims platform. The team could first lift it into a supported hosting environment to reduce immediate infrastructure exposure. Once an integration layer is stable, it could replatform the database onto a managed service, then defer rewriting the underwriting rules engine until the team has isolated the rules and agreed the target behaviour.
That isn't indecision. It separates risk. The organisation gains a safer operating base while avoiding a rushed rewrite of the most business-sensitive component.
Planning Data, Integrations and the API Layer
Data migration needs its own workstream, budget and acceptance criteria. Treating it as a technical task inside the application release guarantees late surprises, because data quality problems surface when business users try real work, not when an extract completes.
Start with field-level mapping. For every source field, record its target field, transformation rule, default behaviour, validation requirement, ownership and treatment of rejected values. The mapping should identify semantic differences, not just matching column names. A source status of “active” may represent several target states, and a legacy customer identifier may need to remain available for audit or reconciliation.
Prove the data before production
Run profiling against representative extracts and record:
- Completeness: Nulls in mandatory fields and missing parent records.
- Uniqueness: Duplicate customers, transactions or identifiers.
- Integrity: Orphan records and broken relationships.
- Sensitivity: Locations of personal, financial and commercially restricted data.
- Reconciliation: Counts, checksums, totals and exception categories.
Run source and target in parallel for a defined period. Each batch should reconcile automatically where possible, with an exception queue for human triage. The business must decide whether an exception is corrected, excluded, archived or accepted with a documented risk.
A data migration specialist should work closely with the integration team, particularly where transformations affect downstream consumers. Organisations needing architecture and implementation support can consider a structured platform integration consultancy for API, middleware and data transformation design.
Sequence interfaces instead of switching them all at once
Catalogue every inbound and outbound touchpoint, then classify it:
- Native connector: Replace a custom path with supported target functionality.
- API gateway route: Expose a controlled service with authentication, rate limits and monitoring.
- Temporary bridge: Preserve a legacy interface until the receiving system is ready.
- Retirement candidate: Remove an interface that no longer supports a live service.
For APIs, test authentication, authorisation, rate limits, idempotency keys, retries and contract compatibility. Contract tests should run before the cutover rehearsal, not after a partner reports that its payload no longer works.
Worked example with a legacy EDI feed
Suppose a distributor is retiring an EDI feed and replacing it with a REST endpoint. First, build the endpoint and run it against a non-production consumer. Next, mirror selected messages to the new route while the EDI feed remains authoritative. Reconcile order identifiers, line items, statuses and acknowledgements, then obtain partner sign-off.
At cutover, stop new EDI intake, drain in-flight messages, confirm the final reconciliation, enable the REST route and monitor acknowledgements. Roll back if messages fail contract validation, reconciliation produces unexplained variances or the partner can't complete its critical transaction flow within the agreed window. Don't delete the EDI bridge until the stabilisation gate has formally passed.
Security, Compliance, Testing and a Clean Cutover
Security, compliance, testing and cutover should produce one evidence package for business approval. Separate workstreams often create separate definitions of “ready”, while the release needs one answer to a simpler question: can the organisation operate the service safely on the target platform?
Map identities and roles from the old environment to the new one. Review privileged access, service accounts, secrets, encryption in transit and at rest, key rotation, audit logging and retention. If the organisation operates in New Zealand, align privacy controls with the Privacy Act 2020. Australian operations may also need sector overlays such as APRA CPS 234, while health environments may need to consider HISO standards.
PwC's New Zealand findings show why this deserves early attention. 59% of respondents identified data and integration management challenges, 56% identified operational risk from failure or loss of vendor support, and 55% identified security vulnerabilities associated with legacy systems. Those figures are reported in coverage of the Landonline transformation and PwC findings. The lesson is practical. Replacing software without sequencing controls and dependencies leaves the underlying risk intact.
Make testing evidence-based
Use a test pyramid with explicit exit criteria:
- Unit testing: Transformation rules, validation logic and rewritten components behave as designed.
- Integration testing: Interfaces authenticate, exchange valid payloads and handle failures correctly.
- Performance testing: The target supports realistic transaction and batch behaviour under expected operating conditions.
- Disaster recovery testing: Recovery procedures, dependencies, backups and access paths work when rehearsed.
- User acceptance testing: Named users complete their priority tasks using realistic scenarios and data.
Every test result needs an owner, evidence location, severity classification and decision. “Tested successfully” isn't sufficient for an executive sign-off.
Write the cutover runbook hour by hour
The runbook should name the action owner, approver, start condition, completion evidence and next decision. Include freeze communications, final backup, data extract, validation, interface switching, user access checks, monitoring activation and support escalation.
Define a rollback window in hours, not days. The release authority should know the latest safe point for reversal and what data must be retained if the target has accepted transactions. The rollback decision can't depend on a committee that is unavailable at the moment a threshold is breached.
A green cutover requires reconciled batch totals, successful completion of users' top three tasks and live monitoring dashboards. A red cutover means the team has unexplained data variances, failed critical workflows, missing observability or unresolved access control evidence.
Security and operational support should continue beyond the release. A managed security service can provide another operating model for monitoring and response, particularly when the internal team is already carrying production responsibilities. See the available managed cybersecurity services when deciding how alerts, incidents and control evidence will be handled after go-live.
Use this short video as a visual prompt for the importance of structured release preparation:
Change Management, Training and the Migration Workflow
Adoption decides whether the migration lands. A technically sound platform still fails operationally when staff don't know which process changed, supervisors can't see unresolved issues or support teams lack a consistent route for escalation.
Start by segmenting users according to role, transaction volume, decision authority and proximity to the change. A warehouse operator needs different preparation from a finance analyst, customer service manager, integration owner or executive approver. Run an impact assessment for each group and identify what stops, what changes and what remains familiar.
Training should be layered:
- Short demonstrations: Show the new screens and the changed workflow in focused videos.
- Role-based practice: Let users complete realistic tasks in a safe environment, including exception handling.
- Floorwalking: Put knowledgeable people close to users during the first cutover so small problems don't become formal incidents.
Turn the programme into visible work
A monday.com board can coordinate the migration if the team designs it around decisions and hand-offs rather than a long task list. Create separate workspaces for architecture, data, integrations, testing, change and operations, then connect dependencies where one workstream cannot proceed without another.
Useful board elements include:
- Status automations: Trigger a communication or approval request when an item changes state.
- Risk forms: Let staff submit issues with a service, owner, impact and due date.
- Decision logs: Record the decision, options considered, approver and evidence.
- Training trackers: Show completion by role, location and manager.
- Hypercare rotas: Make support coverage visible by shift and escalation level.
- Executive dashboards: Surface blockers, gate status, open critical defects and readiness evidence.
Keep the board alive after release
Don't archive the workspace when the target system goes live. Convert it into the hypercare hub, with incident ownership, response targets, known errors, user feedback and daily decisions in one place. This prevents support information from fragmenting across email, chat and vendor ticketing systems.
The board should also hold the communications calendar and go-live decision record. When a status changes from “blocked” to “ready”, the responsible lead should be able to trigger the next communication without manually rebuilding a distribution list.
Adoption rule: If users must ask three different teams where to report a problem, the migration workflow is already failing.
The same operational board can later support optimisation, but remove completed migration tasks and duplicate workflows. A clean board is a management control, not a historical scrapbook.
Post-Migration Monitoring, Optimisation and the Next Modernisation Wave
Go-live starts stabilisation, not completion. The first 90 days need a deliberate operating rhythm, with a clear purpose for each stage. Track service reliability, data quality and whether the new platform delivers the business capability that justified the investment.
Days 1 to 14 focus on hypercare
Track incident volume, batch runtimes, user-reported defects and data reconciliation variances. Hold short daily reviews with named owners, and route every issue to a decision rather than another status update. Spreadsheets, manual queues and workarounds deserve close attention. They often expose a process gap, not an isolated defect.
Keep the legacy platform available only through an approved fallback arrangement. Every access needs a reason, an owner and an expiry decision. Uncontrolled parallel operation creates conflicting records and weakens confidence about which system is authoritative.
Days 15 to 45 are for stabilisation
Shift from emergency response to targeted optimisation. Review slow queries, integration latency, failed retries, alert quality, user feedback and cost allocation. Fix the issues affecting service reliability first, then improve convenience and performance.
Connect application logs, infrastructure metrics, integration traces, batch outcomes and business transaction checks through a lightweight observability setup. Hold weekly service reviews with the business owner, service desk, platform lead, security representative and relevant vendor contacts. Keep the work-management board as the operational record, with each improvement tied to an owner, decision and outcome.
Days 46 to 90 harden the estate
Complete operational documentation, recovery rehearsals, access reviews and monitoring handover. Confirm which temporary bridges can be removed, which archives must be retained and when legacy components can be decommissioned. Inland Revenue's experience, with hundreds of applications retired through a multi-year programme, shows that shutdown is a managed delivery stream rather than an afterthought. Use the earlier legacy system guidance as a reference, but establish programme-specific controls and owners.
Bring in managed services support when internal teams cannot sustain monitoring, incident response, patching or control evidence alongside normal operations. That is a capacity decision. It protects the service while the internal team continues modernisation.
The next wave should start with remaining technical debt and the business case that funded the first migration. Retire duplicate workflows, remove unnecessary integrations and test proposed capabilities against measurable service outcomes. A migration succeeds when it creates a simpler operating model, not when it relocates yesterday's complexity.
Wisely helps organisations plan cloud readiness, connect legacy platforms through APIs and middleware, and coordinate migration work with practical change control and post-go-live support. Visit Wisely to discuss a structured legacy system migration plan for your New Zealand or Australian organisation.
