Users bring real histories, real workflows, and data that may behave differently from what we see in lower environments.

For me, reducing migration risk means preparing for that transition throughout the project. It includes how we test, how we introduce users to the change, and how we learn before opening the new application to everyone.

UAT needs people who understand the business

I think user acceptance testing is most useful when the testers understand both the business and the legacy application.

They know what a successful workflow means beyond whether the page loads or the form submits. They can recognize when a result differs from the existing behavior and help determine whether that difference is intentional.

That matters because modernization often includes two kinds of change: behavior we want to preserve and improvements we have agreed to introduce.

If we don’t distinguish them, an intentional change can be reported as a defect, while an unintended change can be dismissed as part of the new system.

I’d want UAT scenarios tied to the decisions made during discovery. What are we preserving? What are we changing? What should the user see in each case?

Test the transition as well as the replacement

When the applications run side by side, testing only the new one leaves part of the solution unchecked.

We also need to test their interaction.

Does an update in one application appear where it should in the other? Can users move between them without losing the state they need? Do both produce consistent results for behavior we have agreed to preserve?

Backend and frontend unit tests have a role in this. So do integration tests and business workflow tests.

I wouldn’t treat a coverage percentage as proof that the migration is ready. The useful question is whether the tests address the failures that would matter during the transition.

Prepare users before asking them to change

Risk reduction also includes helping users understand the new experience.

That can start inside the legacy application: notices about the upcoming change, an explanation of what to expect, and a clear path to learning more.

Tutorials and onboarding can help users navigate the replacement. The amount of preparation should match the amount of change.

If we have preserved the interface and behavior, users may need less guidance. If we have changed a familiar workflow, we need to explain how they will complete their work in the new version.

I think that belongs in the launch plan alongside technical readiness. Users should have somewhere to take questions and report problems.

Why we use a soft launch

One approach my team uses is a soft launch.

We deploy the new version to production but expose it to a small subset of users. In some cases, selected users are automatically redirected to the new experience after login.

That gives us an opportunity to observe the replacement with real production data and real usage.

Lower environments often don’t accurately reflect production data volumes or behavior. A soft launch helps us look for issues that those environments may not reveal, including how APIs respond to real user histories and production conditions.

It also gives us feedback from people completing actual work.

A small cohort won’t reproduce the load of a full rollout, so I’d still treat performance validation as a separate responsibility. The value of the soft launch is that it adds production evidence to what we already know.

Make the small rollout deliberate

A soft launch needs boundaries.

I’d define who is included, how they reach the new application, and what we need to learn before expanding access. A representative group is more useful than simply choosing the easiest users.

The observations should include both technical and user outcomes:

• Can users complete the important workflows?

• Does their data appear and behave as expected?

• Are API response times acceptable for those workflows?

• Are errors or synchronization problems appearing?

• What are users finding confusing?

I’d also decide in advance what would cause us to pause or reduce exposure.

The goal is to make the next rollout decision based on evidence, with someone clearly responsible for making it.

Recovery needs to account for data

Limiting exposure gives us room to respond, but it doesn’t automatically make every change reversible.

If users create or update information in the new application, sending them back to the old one raises questions about those changes.

That connects directly to the data-migration discussion in Part 3. We need to know which system owns writes, how changes are synchronized, and what recovery would require.

I’d want the recovery plan to describe what happens to users and their data, rather than stopping at “redeploy the old version.”

Launch is a sequence of decisions

For me, a migration launch is more manageable when readiness is demonstrated in stages.

Business-aware testing helps establish that the replacement supports the right behavior. User preparation helps people understand the transition. A soft launch lets us learn from a controlled production rollout before expanding access.

None of those steps removes every risk. Together, they give the team better information and clearer opportunities to respond.

Across this series, I keep coming back to the same idea: the migration approach, business behavior, data, and rollout plan need to be discussed together.

The newer stack is only one part of what makes the migration work.

This is Part 4 of the Legacy Application Migration series. Start with Part 1.

Extract the data. Transform it. Load it into the new system.

Those steps matter. But before choosing how to move the data, I think we need to agree on what it means in the replacement.

A successful load tells us the destination accepted the records. It doesn’t tell us whether the application will interpret them correctly.

The migration approach shapes the data plan

In Part 1, I talked about the constraints of keeping the legacy application running alongside its replacement.

Data is one of the places where that constraint becomes concrete.

A database redesign might make sense for the new application. But if the legacy application still needs the current structure, we have to decide how both systems will continue to operate during the transition.

Will they share a database? Will the replacement have its own data model? Which system can update which information? How will changes reach the other system?

Each choice creates work. I’d want those responsibilities agreed before treating the data migration as a separate implementation task.

Map meaning before mapping columns

A source-to-target mapping should explain more than where a value goes.

Consider a hypothetical legacy field called status. A value might mean “active” in one workflow but “available for a specific group” in another. Moving it into a new boolean field could lose a distinction that the business still needs.

Before simplifying that model, I’d ask:

• What does each source value mean?
• Which workflows use it?
• Are there exceptions or historical values?
• What should happen when a value doesn’t fit the new model?
• Who can approve that interpretation?

The transformation rule should follow those answers.

This is also where business analysts and stakeholders are useful. A developer can identify how code uses a value; the business can help decide whether that behavior should continue.

Decide what deserves to move

Preserving behavior doesn’t necessarily mean moving every historical record into the same place.

I’d separate the decisions about active data, historical data, and information that no longer serves the application. That is a business decision as much as a technical one.

For example, an old record might no longer appear in a user workflow but still be needed for reporting. Another might be obsolete, duplicated, or incomplete.

The important thing is to make the treatment explicit. Migrate it, retain it elsewhere, resolve it, or exclude it through an approved decision.

I wouldn’t want a migration script to make that decision accidentally because a record failed validation.

Give synchronization an owner

If users keep working in the legacy application while migration is underway, the source continues to change.

That means an initial bulk load is a starting point.

We need a plan for changes made afterward: newly created records, updates, and deletions. We also need to define when the old system stops accepting changes and when the replacement becomes authoritative.

For me, the most useful questions are simple:

Who owns writes during each stage? How do we identify changes? What happens if a synchronization step fails? How do we know the destination has caught up?

The answers may differ by migration approach. The responsibility for answering them should be clear.

Validate what the business will see

Record counts are useful, but I wouldn’t use matching counts as the definition of success.

Two systems can contain the same number of records and produce different results.

I’d validate at several levels:

For a hypothetical training platform, that could mean checking whether a user’s completion history produces the expected course eligibility. The presence of the completion record alone wouldn’t be enough.

That is why I value testers who understand the business and the legacy behavior. They can help validate the meaning of the migrated data.

Rehearse the transition, including what happens if it fails

I’d want the migration rehearsed with representative data before the final cutover.

A rehearsal should test more than whether the script runs. It should help establish how long the process takes, what fails, how exceptions are handled, and how we verify readiness.

It should also address recovery.

If the replacement has already accepted new writes, switching users back to the legacy application can create another data problem. Where do those new changes go? Can the old system interpret them? Who reconciles the differences?

I’d rather resolve those questions while designing the transition than discover that our rollback plan only covers deployment.

What I would call a successful data migration

For me, success means the replacement contains the information it needs, interprets it correctly, and has a clear owner for future changes.

The load process is part of that outcome. So are the mapping decisions, validation, synchronization, and cutover plan.

That is why I would bring the data discussion into the architecture conversation early. It affects how we build the replacement and how we get users there.

This is Part 3 of the Legacy Application Migration series. Start with Part 1. The final article will cover testing, user readiness, and reducing risk through a soft launch.

A login page. A search. A few forms. Some reports.

But a list of screens doesn’t tell us everything the replacement needs to do. It tells us what users can see. The migration also has to account for the decisions, dependencies, and assumptions behind those screens.

In the first article, I talked about choosing a migration approach. The next question is what we actually know about the application we’re moving.

Start with behavior, not just features

For me, “we need to migrate this feature” should lead to another conversation: what behavior does the business rely on?

A useful way to explore that is to take one workflow and follow it beyond the UI.

What makes a user eligible to perform an action? What changes after they complete it? Does another system receive an update? Does a report depend on the result? What happens when the external system is unavailable?

Those questions can change our understanding of the feature.

Consider a hypothetical training application. Two users may see different course options because of their brand, role, or completion history. Rebuilding the course-list screen is only part of the work. The replacement also needs to preserve the rules that determine which courses each user should see—or replace those rules through an explicit business decision.

I’d rather make that decision during discovery than have a tester uncover it close to launch.

The same application can mean different things to different stakeholders

One challenge in modernization is bringing together stakeholders who have different expectations.

An application may support multiple brands or business groups. A shared workflow can have variations that matter to each group, even when the underlying code is mostly the same.

That makes “the business has approved it” too broad to be useful on its own. Which stakeholders reviewed it? Which variations did they consider? Did they agree on the behavior we’re preserving and the behavior we’re changing?

I think business analysts and stakeholders need to be part of these conversations early. They can help explain current behavior, but they also need to describe the future vision.

Otherwise, we can build a technically cleaner replacement that still makes the next business change difficult.

Follow the dependencies in both directions

An integration list is a useful starting point. I’d also ask what each integration expects from the application.

For every important dependency, I want to understand:

• What information enters or leaves the application?
• What triggers the exchange?
• Which system owns the information?
• What happens if the exchange fails or runs late?
• Who can confirm that the replacement behaves correctly?

A successful API response doesn’t answer all of those questions. The information may still be incomplete, arrive at the wrong time, or have a different meaning to the receiving system.

The goal is to understand the contract the business relies on, including timing and failure behavior.

Coexistence makes discovery more important

In a phased migration, the legacy application remains part of the solution for a while.

That means we need to understand more than how the replacement should behave independently. We also need to understand how the two applications will work together.

If both can update related information, which system is authoritative? If we change a rule in the replacement, does the legacy application still produce a compatible result? If a user moves between the two, does their state follow them?

These are architecture questions, but they depend on understanding the existing application.

It’s difficult to design reliable coexistence around behavior we haven’t identified.

Bring the right people into the work early

Team knowledge gaps haven’t been a major issue in my experience when good people are hired and involved from the beginning.

That’s my experience, rather than a claim that knowledge transfer is always easy.

What matters to me is giving the people building and testing the replacement access to the context they need. Business conversations shouldn’t happen in one group while implementation decisions happen in another, with the two meeting only at UAT.

I want the team to hear why a workflow matters, where it varies, and what the business expects to become easier after migration.

Turn assumptions into reviewable decisions

I’d keep a small discovery record for each important workflow:

This doesn’t need to become a large document before development starts. It needs to make uncertainty visible and help the team close it.

For me, that is where discovery earns its place in the migration plan. It gives us a clearer definition of what we are replacing—and which decisions we are making deliberately.

This is Part 2 of the Legacy Application Migration series. Start with Part 1. Next, I’ll look at data migration and why moving records is only part of the work.

Assess the existing system. Pick the new technology. Move the functionality. Test. Launch.

But once you get into the work, you realize you’re moving more than an application. You’re moving years of business logic, data, and integrations—and making decisions about how much of that history the new system should carry forward.

I’ve worked on legacy application modernization, and one of the first decisions I think teams need to spend time on is the migration approach. Do we replace the application in one go? Move it in phases? Keep the existing behavior and modernize what runs underneath it?

Those choices affect much more than the project timeline.

Big bang: more freedom, a bigger commitment

A big-bang approach gives you the opportunity to rethink the application more broadly. You can revisit the architecture, redesign the database, and question decisions that made sense when the original system was built.

That freedom is attractive. If we’re investing in modernization, why carry every old limitation into the new application?

But that freedom needs time and budget. The replacement has to be ready for the scope you’re cutting over, and that means understanding the existing functionality well enough to know what “ready” actually means.

For me, the question isn’t simply whether a new architecture would be better. It’s whether the project has the room to deliver that change while preserving the behavior the business still relies on.

Phased migration: you keep the business running, but the legacy system stays in the picture

With a phased or side-by-side approach, you keep the legacy application running while you build and introduce the new one.

That can make the transition more manageable. You don’t have to move everything at once, and you can learn from the parts you introduce before moving further.

But there’s a tradeoff that I think deserves more attention: the new application still has to work alongside the old one.

You may want to redesign the database, but the legacy application still depends on its current structure. You may want to simplify business logic, but both applications need to produce consistent results. You inherit existing data, and you may spend part of the project maintaining two applications.

So phased migration doesn’t automatically give you complete freedom to build the new system however you want. Some decisions remain constrained by coexistence.

I think that’s something to acknowledge early. Otherwise, we can promise a fresh architecture while planning a transition that still requires compatibility with the old one.

Sometimes preserving behavior is a useful starting point

There’s also a case for keeping the interface, functionality, and much of the existing business logic unchanged while modernizing the underlying system.

I find that attractive because it reduces the number of things changing at the same time. The business already understands the functionality, and users already know how to work with it. Preserving that behavior can make the migration simpler.

It helps to be precise about what we’re changing. Moving an application to new infrastructure and rebuilding it on a newer stack are different scopes, even when both preserve the same user experience. What I’m talking about here is the choice to keep current behavior as the baseline.

That doesn’t mean every existing decision should become permanent.

Even when we’re preserving functionality, I think we still need to talk to business analysts and stakeholders about the future vision for the application. What features do they expect to add? Where does the application need to grow? What is difficult to change today?

Those conversations help us design the modernized system so that future additions are easier. Otherwise, we risk moving the application and carrying its limitations along with it.

The migration approach and the future architecture need to be discussed together

I don’t think there’s one migration strategy that wins every time.

A big-bang replacement gives you more room to rethink the system, but asks for a larger commitment before the transition. A phased approach lets you introduce change gradually, but requires you to account for coexistence. Preserving current behavior can simplify the scope, but you still need a plan for what comes next.

The questions I would put on the table early are:

• How much of the application are we trying to change in this project?

• Does the legacy application need to keep running alongside the replacement?

• What does that mean for the database and business logic?

• Do we have the time and budget for the scope we’re choosing?

• What should become easier to build after this migration?

I’d rather work through those questions before the team gets too attached to a particular solution. They shape the architecture just as much as the technology choices do.

What I keep coming back to

For me, modernization starts with understanding what we need to preserve, what we want to change, and what the transition will allow us to change right now.

The existing application contains accumulated business decisions. Some still matter. Some may need to be revisited. Choosing a newer stack doesn’t make that distinction for us.

That’s why I see the migration strategy as an architecture decision in its own right. It determines how we get to the new system—and how much freedom we have along the way.

This is the first post in a four-part series on legacy application migration. Next, I’ll get into the hidden complexity that surfaces when you start looking closely at the existing system, followed by data migration and reducing risk during the transition.