90–180 Day Pilots Reduce Risk: Legacy System Migration for Swiss IT

For most organizations, incremental legacy system migration, run through a pilot and a guarded phased go-live, delivers a better balance of risk, cost, and business value than a single cutover. Governance and data protection decisions matter more to the outcome than which vendor or platform you pick. Done right, the payoff is lower operational risk during the transition, and a clear picture of total cost of ownership before you commit further budget.

---

TL;DR:

• Most organizations benefit from incremental migration approaches, including phased go-lives and MVPs, rather than a single big-bang cutover, to reduce operational risk.

• Dependency mapping should focus on undocumented departmental applications and small systems, which often hold critical workflows unseen in official diagrams.

• Data classification and compliance considerations, especially for personal data under Swiss law, require early planning and contractual safeguards before migration begins.

• The choice of migration approach depends on the current system’s technical debt, coupling, and the organization’s tolerance for downtime during transition.

• A structured plan with assessment, pilot, and phased go-live stages, including a clear rollback strategy, outperforms plans driven solely by target dates.

---

What Legacy System Migration Actually Means (and When to Start One)

Legacy system migration is the process of moving data, functionality, and workflows off an aging platform onto new infrastructure, whether that’s a modern cloud environment, a new application, or a rebuilt version of the same system. It’s a narrower term than “modernization,” which also covers changes that don’t require moving anything, such as adding an API layer to a system that stays exactly where it is. A migration always involves data and functionality changing location or platform. Modernization is the broader goal; migration is often the mechanism.

You don’t need a crisis to justify starting one, but most organizations wait until they have one anyway. The clearest triggers are external: a vendor announces end-of-life for the platform, a compliance audit flags unsupported software, or a new integration simply can’t happen because the legacy system has no usable API.

A few warning signs tend to show up before the trigger event does:

• Change lead time keeps growing. A feature that took two weeks to ship five years ago now takes two months because nobody fully understands the dependencies anymore.

• The vendor has exited the market, stopped patching, or been acquired and deprioritized.

• Security incidents or near-misses are increasing, often tied to unpatched components that can’t be updated without breaking something else.

• Maintenance costs are climbing faster than the business value the system delivers.

• New hires can’t be onboarded onto the system without months of tribal-knowledge transfer from one or two people who built it.

If two or more of these apply, it’s worth starting an assessment even before the budget conversation happens. Waiting for the vendor to force the issue almost always means migrating under worse time pressure and with less negotiating leverage.

Comparing Migration Approaches: Lift-and-Shift, Replatform, Refactor, and the Strangler Pattern

There’s no single “correct” migration approach. The right one depends on how much technical debt the current system carries, how tightly it’s coupled to other systems, and how much risk the business can tolerate during the transition.

Lift-and-shift moves the application as-is onto new infrastructure, usually cloud servers, with minimal code changes. It’s the fastest and cheapest option upfront, and it’s a reasonable choice when the application logic still works fine but the underlying hardware or hosting is the actual problem. The downside: you inherit every architectural flaw the old system had, just running on newer infrastructure. It buys time, not improvement.

Replatforming makes moderate changes, often swapping the database engine or adjusting the application to work with cloud-native services, without a full rewrite. It sits in the middle on cost and risk, and it’s often the right call when the application’s business logic is sound but its data layer or deployment model is the bottleneck.

Refactoring or full rewrites rebuild the application on modern architecture, sometimes rethinking the data model and workflows entirely. This is the most expensive and time-consuming path, but it’s the only one that actually removes technical debt rather than relocating it. It makes sense when the business logic itself needs to change, not just the infrastructure underneath it.

The strangler pattern replaces the legacy system piece by piece, routing new functionality to modern services while the old system keeps running the parts nobody has migrated yet. Over time, the legacy footprint shrinks until it can be retired. This approach avoids the all-or-nothing risk of a big-bang cutover and lets you deliver business value incrementally rather than waiting years for a single go-live. Modernization guidance from Swisscom recommends exactly this: start with MVPs in the public cloud, integrate them back into the legacy environment, and build toward a hybrid state rather than attempting one large jump.

The choice usually comes down to how coupled your systems are and how much downtime the business can absorb. A tightly coupled monolith with dozens of integration points almost always favors the strangler pattern or a phased replatform over a rewrite, simply because a full rewrite delays every dependent integration until the very end.

Building a Legacy System Migration Plan That Survives Contact With Reality

A migration plan built entirely around a target go-live date, without staged checkpoints, tends to fall apart the moment the first unexpected dependency surfaces. A better structure has three phases, each with a concrete deliverable that gates the next.

1. Assessment. Before writing a line of migration code, you need a full application inventory, a dependency map showing which systems talk to which, a data classification exercise separating personal data from operational data, and a cost and risk profile for the current state. This phase routinely takes longer than teams expect, mostly because dependency mapping surfaces integrations nobody remembered existed.

2. Pilot or MVP. Pick one workload, ideally low-risk but representative of the broader system’s complexity, and migrate it fully. The goal isn’t speed; it’s validation. A successful pilot proves the chosen migration approach handles your actual data volumes, your actual integration patterns, and your actual performance requirements, not a simplified test case. Define success criteria before you start: data fidelity checks passing, performance within an agreed threshold, and rollback tested and working.

3. Phased go-live. Sequence the remaining workloads by risk, moving the lowest-risk, lowest-visibility systems first. Each phase needs its own runbook, its own monitoring dashboard, and a tested rollback path before it goes live, not after. AWS’s Migration Acceleration Program frames this as a three-stage progression from assessment through mobilization to migration and modernization, and it specifically calls out leadership commitment as a bigger predictor of success than the technology stack chosen.

Pro Tip: Treat your rollback plan as a first-class deliverable, not an afterthought. If you can’t answer “how do we revert this phase in under four hours” before go-live, you’re not ready for go-live.

Budget contingency belongs in this plan explicitly. Gartner-linked analysis of failed technology projects points to weak alignment between technical milestones and business objectives as a leading cause of abandonment, along with unchecked total cost of ownership creeping past what leadership approved. Tying each phase to a measurable business outcome, not just a technical checkpoint, keeps the project defensible when budget conversations get tense.

Data Migration, Privacy, and What Swiss Law Actually Requires

Cataloging and classifying your data comes before any technical migration work starts, not alongside it. Separate personal data from purely operational or business data early, because the two carry very different compliance obligations once they leave your current infrastructure.

Under Switzerland’s Federal Act on Data Protection (FADP), the organization stays legally responsible for personal data even after handing processing to a cloud provider or outsourcing partner. Outsourcing does not transfer liability. If your migration moves personal data to a cloud service, especially one outside Switzerland, you need documented technical or contractual safeguards, and the EDÖB (the Federal Data Protection and Information Commissioner) expects those safeguards to be in place before the transfer, not retrofitted afterward. The EDÖB’s own case history includes a formal review of SUVA’s outsourcing of personal data to a Microsoft cloud service, which underscored that even large, well-resourced organizations need an independent privacy risk assessment before finalizing a cloud outsourcing decision.

Practical controls that hold up under regulatory scrutiny include:

• Pseudonymizing or anonymizing personal data wherever the business use case allows it, reducing exposure if a breach occurs.

• Encrypting data both at rest and in transit, especially for any cross-border transfer.

• Maintaining audit trails showing who accessed what data during and after migration.

• Running vendor due diligence questionnaires before signing any outsourcing contract, not after.

• Building contractual clauses covering data location, breach notification timelines, and subcontractor use.

The EDÖB generally reviews standard data protection clauses within a few months, according to its own outsourcing guidance, which is worth factoring into your project timeline if your migration depends on a new cross-border data processing agreement. Build that review window into your plan rather than discovering it during the pilot phase.

Technical Challenges: Dependencies, Databases, and Integration Patterns

Dependency mapping is where most migration timelines go wrong, and it’s almost never the systems everyone knows about that cause the delay. It’s the small departmental applications, often called Fachanwendungen in German-speaking environments, built by a business unit years ago and never formally documented, that quietly hold critical workflows together. Finding these requires talking to the people who actually use the system daily, not just reading the architecture diagram someone drew five years ago.

Database migration carries its own set of realities that teams underestimate. Schema changes need data fidelity checks at every step, comparing record counts, checksums, and sample records between old and new systems before you trust the migration. Performance tuning on the new platform almost always requires a different approach than what worked on the legacy database, particularly if you’re moving from an on-premises relational database to a cloud-native or in-memory alternative. Test-data strategies matter here too: testing against a scrubbed production copy catches issues that synthetic test data never will.

For integration, three patterns handle most situations:

• API façades wrap the legacy system in a modern interface, letting new applications talk to it without touching the old code.

• Adapters and message buses decouple systems that used to talk directly, reducing the blast radius when one side changes.

• Incremental cutovers route a percentage of traffic to the new system while the rest stays on the old one, letting you catch problems at small scale before committing fully.

Pro Tip: Automate your rollback the same way you automate your deployment. A manual rollback under pressure, during an incident, at 2 a.m., is where migrations turn into headlines. Infrastructure as code, continuous integration and delivery pipelines, and automated test suites all reduce the odds that a phased cutover becomes a fire drill. Bühler’s SAP S/4HANA migration illustrates the payoff of disciplined data work specifically: the company’s selective data transition cut operational data volume from an initial several terabytes by a significant amount, which directly shaped how much in-memory database infrastructure they needed to buy.

Governance, Change Management, and What Success Actually Looks Like

A migration without an executive sponsor tends to lose funding the moment it hits its first real obstacle, which every migration does. A governance board with both business and IT executives, meeting on a fixed cadence, gives the project a place to resolve scope disputes and budget overruns before they become political.

Change management runs in parallel with the technical work, not after it. That means training scheduled around the pilot and each go-live phase, a communication plan that tells affected teams what’s changing and when, and a staged user rollout so support teams aren’t fielding questions from the entire organization on day one.

Measure success against a small set of concrete metrics:

• System availability during and immediately after each go-live phase, compared against the legacy baseline.

• Data integrity, verified through the fidelity checks built during the migration itself.

• Support cost delta, tracking whether ticket volume and severity actually drop post-migration.

• Business KPIs tied to the original justification for the migration, whether that’s faster order processing, reduced compliance risk, or lower licensing cost.

FinOps discipline matters just as much once the migration lands. Cloud spend, and increasingly AI-related workload costs, has a habit of creeping upward quietly after go-live if nobody owns continuous cost monitoring. Assign that ownership before the migration finishes, not after the first surprising invoice arrives.

Proof That Staged Migration Works: Two Swiss Examples

The Swiss Federal Administration’s migration to SAP S/4HANA used a staged implementation deliberately, learning from each rollout phase before expanding to the next part of the productive system. Bühler took a similar path with its selective data transition, cutting data volume before scaling infrastructure investment around the leaner dataset.

Some firms apply a staged, senior-led philosophy to legacy system migrations.

• Senior engineers ideally stay involved on projects from first consultation through handover to avoid mid-project rewrites that can occur when teams change.

• Our legacy migration and replatforming work covers the same phased assessment, pilot, and rollout structure described above.

• Related system integration and API development work supports the dependency mapping and façade patterns migrations depend on.

A compact team with fewer handoffs tends to retain more context between phases than larger teams with frequent rotations.

Your Next Steps Before Committing to a Migration Date

Before you set a go-live date, get these in place:

1. Complete an application and data inventory, including the Fachanwendungen nobody’s documented yet.

2. Name an executive sponsor and assemble a governance board with both business and IT authority.

3. Scope a pilot covering one representative, low-risk workload with clear success gates.

4. Run vendor due diligence, including data protection clauses, before signing anything.

5. Set a 90 to 180 day pilot timeline with a hard checkpoint for the go or no-go decision.

6. Loop in security, legal, data owners, operations, and a senior technical lead from day one, not after the pilot starts.

Budget contingency for at least one unplanned dependency. There’s always one.

How Ampersand Labs Supports a Staged Legacy System Migration

Ampersand Labs runs migrations the same way we run any client engagement: senior engineers involved from the first conversation through handover, so nothing gets rewritten halfway because a new team inherited someone else’s assumptions. That continuity is the whole point when a migration spans months and multiple phased go-lives. If your organization is weighing whether a lift-and-shift, a replatform, or a full strangler-pattern approach fits your systems, a discovery call is the fastest way to find out before committing budget. We can also help with the API and system integration work that most legacy migrations depend on, and with ongoing software maintenance and monthly support once the new system is live. Browse our case studies to see how staged delivery has worked for other Swiss organizations, then reach out through our legacy migration service page to scope a migration readiness audit.

FAQ

Why Won’t Legacy Security Systems Scale in 2026?

Legacy security systems typically weren’t built for cloud-scale traffic, modern authentication standards, or the API integrations current applications require. Patching them further usually just adds complexity without addressing the underlying architecture, which is why security risk is one of the most common triggers for starting a migration.

What Is Legacy Data Migration?

Legacy data migration is the process of extracting, transforming, and loading data from an outdated system into a new platform while preserving accuracy and completeness. It requires classifying data first, separating personal data from operational data, and running fidelity checks that compare old and new records before cutover.

How Do You Transfer Data From a Legacy System to SAP?

Transferring data to SAP, including SAP S/4HANA, generally follows an assessment, pilot, and phased rollout structure, often paired with a selective data transition that migrates only the data still needed operationally. Bühler used exactly this approach and cut its operational data volume significantly before scaling its new infrastructure.

How Many Companies Still Use Legacy Systems?

There’s no single universal figure, since “legacy” covers everything from decades-old mainframes to five-year-old applications nearing end-of-life support. What’s consistent across industries is that most mid-size and public-sector organizations carry at least one system old enough to create integration, security, or compliance risk, which is why staged migration planning stays relevant regardless of exact prevalence.

What Does Ampersand Labs Charge for a Legacy System Migration?

Pricing depends on the scope of the migration, whether it’s a full replatform, a system migration, or a targeted integration project, and current rates are available directly through Ampersand’s pricing page. A discovery call is the fastest way to get a scoped estimate for your specific systems.

Recommended

• Die Mitte: Running 600+ websites for a Swiss political party from one system.

• Arthouse Kinos: A new website and ticket shop for Zürich’s most iconic cinemas.

• Repa Immobiliare: Getting a property portfolio off paper, with software that never goes online.