In this lesson, we'll discuss the first migration tip - preparing a migration plan.

It sounds easy and obvious that when you have a detailed plan, it is easier to migrate an application.
Once again, we'll consider a few cases
and point out the most important parts that need to be checked or fixed before starting the migration.

You can implement it in the way you like.
For me, it always has been an instruction or checklist.

You can spend any amount of time you need preparing yourself for action.


It's better to sacrifice that time before when migration is still not in progress
because after migration starts, every issue will block the rest of the team, and you'll be forced to work in a hurry.
With a good plan, you'll be able to predict issues that may happen and solve them quickly.

It will let you avoid a lot of unnecessary stress at work,

 which is another important advantage of having a plan.

Sometimes, when you start preparing the plan,
you'll notice that some parts of the application should be changed or refactored.
In that situation, I encourage you to put this task in the plan as things that have to be done before migration starts.

This lesson is focusing on the cases from the previous lesson:

I want to remind you once again that every application and organization is different and unique.
We're focusing on the most popular cases so that you can use them as a reference point.

As we noticed in the previous lesson, the codebase size will be the biggest problem.
Luckily, you have only one application to migrate.
No matter if your organization is built by one or multiple teams,
I would suggest doing the dry run whenever you deal with complex applications.
You'll learn about dru runs later in this lesson.

The second problem that you have to address is a tight schedule.
Because there's only one application, every action you need to do will be blocked for others.
My suggestion here is to do migration when you're sure that no one is working on the code, for example, on a weekend.

Try to have a fallback plan.
If something happens,
and your migration is not completed on time,
you will need to decide if you want to continue and block other developers for a while,
or abandon the task, revert changes, and repeat migration later.

This is the easier case. You can make all coworkers involved in migration tasks.
This is one of the possible solutions that will save you from blocking other people and working on weekends.

The other important aspect you may want to get everyone involved is
that there will be more people who know about the problems you approached and the solutions you applied.

In most cases, when you have multiple teams working on one application, there's no option
to avoid blocking other developers.
Make sure that every team knows about the changes you want to make.
It's worth discussing NX's recommended layout and the plan with the rest.

I suggest adding to the plan when and what you want to share with others.

As developers, we tend to share too many (because technical stuff is awesome) technical details.
In the early stages,
it's usually better to share only the most important information
that will allow us to work with a brand-new NX mono repository.
Later, when everyone is familiar with the basics of NX mono repositories, you can share more details.

In this case, no matter if your organization is built by one or multiple teams,
you can extract libraries only after the migration of the whole application.
The non-detailed plan will look like this:

---
title: Tips. The migration plan
description: How to plan the migration process
privateVideoUrl: https://stream.mux.com/AZclGI3A2K5gOB016VqHNsRMZSesFHA6Rhbyg1IF5bUg.m3u8
---

In this lesson, we'll discuss the first migration tip - preparing a migration plan.

It sounds easy and obvious that when you have a detailed plan, it is easier to migrate an application.
Once again, we'll consider a few cases
and point out the most important parts that need to be checked or fixed before starting the migration.

The migration plan is just a concept. **You can implement it in the way you like.
For me, it always has been an instruction or checklist.**

Making the plan has one huge advantage.
**You can spend any amount of time you need preparing yourself for action.**
It's better to sacrifice that time before when migration is still not in progress
because after migration starts, every issue will block the rest of the team, and you'll be forced to work in a hurry.
With a good plan, you'll be able to predict issues that may happen and solve them quickly.
**It will let you avoid a lot of unnecessary stress at work,** which is another important advantage of having a plan.

:::note

Sometimes, when you start preparing the plan,
you'll notice that some parts of the application should be changed or refactored.
In that situation, I encourage you to put this task in the plan as things that have to be done before migration starts.

:::

This lesson is focusing on the cases from the previous lesson:

-   One huge application

    -   One small team
    -   Multiple teams
-   Multiple small applications

    -   One small team
    -   Multiple teams
-   Multiple big applications

    -   One small team
    -   Multiple teams
-   One small application

    -   One small team

I want to remind you once again that every application and organization is different and unique.
We're focusing on the most popular cases so that you can use them as a reference point.

![The plan](https://d2uusema5elisf.cloudfront.net/courses/building-angular-applications-with-nx/module_07/lesson_07.05/public/images/06-05-01.png)

## One huge application

As we noticed in the previous lesson, the codebase size will be the biggest problem.
Luckily, you have only one application to migrate.
No matter if your organization is built by one or multiple teams,
I would suggest doing the dry run whenever you deal with complex applications.
You'll learn about dru runs later in this lesson.

The second problem that you have to address is a tight schedule.
Because there's only one application, every action you need to do will be blocked for others.
My suggestion here is to do migration when you're sure that no one is working on the code, for example, on a weekend.

Try to have a fallback plan.
If something happens,
and your migration is not completed on time,
you will need to decide if you want to continue and block other developers for a while,
or abandon the task, revert changes, and repeat migration later.

![The fallback plan](https://d2uusema5elisf.cloudfront.net/courses/building-angular-applications-with-nx/module_07/lesson_07.05/public/images/06-05-02.png)

### One small team

This is the easier case. You can make all coworkers involved in migration tasks.
This is one of the possible solutions that will save you from blocking other people and working on weekends.

The other important aspect you may want to get everyone involved is
that there will be more people who know about the problems you approached and the solutions you applied.

### Multiple teams

In most cases, when you have multiple teams working on one application, there's no option
to avoid blocking other developers.
Make sure that every team knows about the changes you want to make.
It's worth discussing NX's recommended layout and the plan with the rest.

I suggest adding to the plan when and what you want to share with others.

:::tip

As developers, we tend to share too many (because technical stuff is awesome) technical details.
In the early stages,
it's usually better to share only the most important information
that will allow us to work with a brand-new NX mono repository.
Later, when everyone is familiar with the basics of NX mono repositories, you can share more details.

:::

In this case, no matter if your organization is built by one or multiple teams,
you can extract libraries only after the migration of the whole application.
The non-detailed plan will look like this:

1.  Investigate what will change after the migration
2.  Prepare necessary changes that will fix migration blockers
3.  Inform all teams about the coming migration. Everyone should know about the most important changes that will impact everyday work
4.  Proceed with a dry-run and create detailed instruction
5.  If you have approached any blockers that cannot be fixed on the fly, plan the fixes and, when ready, re-run the dry-run
6.  Use the instruction from dry-run to migrate the application
7.  Fix post-migration problems reported by the rest of the teams
8.  Analyze and extract libraries
9.  Done

galczo5

Tips. The migration plan

In this lesson, we'll discuss the first migration tip, preparing a migration

It sounds easy and obvious that when you have a detailed plan, it's easier to

We'll consider a few cases as previously and we'll speak what is important to

You can implement it in the way you like, it might be a total lease, it might

For me, it always has been an instruction or checklist.

You can spend any amount of time for preparation, then you can use the plan for

quick action and migrate everything in shorter period of time.

And if you ask me, I prefer to spend my time preparing when I'm safe and I'm

then spending my time when I'm stressed and I don't want to block my coworkers

So for me, the biggest advantage of having a migration plan is that you can

and then you can avoid a lot of unnecessary stress at work.

So let's start with one huge application.

As we noticed in previous lesson, the codebase size will be the biggest problem

Luckily, we have only one application to migrate.

In this case, I'm always suggesting doing a dry run.

Create a new branch, start migrating, write down all the steps you had to do,

all the small fixes, all the CI actions and so on.

Then use the plan you created by doing a dry run, run it again to validate if

then delete both branches and you are prepared for real migration.

Because application is huge and if you have multiple teams, you don't want to

If something happens, I don't know, some process will blow up, something will

and you cannot proceed with migration, it's always good to have a go back plan

then prepare a new migration plan, solve all the problems and then just try to

So in this case, when you have one future application, I understand that it has

multiple teams across multiple years, you will have some custom things in your

So having two plans, migration plan and the go back plan is really nice

One more important thing, when you have multiple teams, it's very unlikely that

be involved in migration. You should spread information about migration before

itself, you can show them the plan, you should update your co-workers during

of course you should summarize for all and you should pass all necessary

migration. And there's one more tip that I want to share with you, if you work

applications with multiple teams, as developers we tend to share too many

because we think it's awesome, we are passionate about it. And in the early

it's usually better to share only the most important information, just not to

and then you can share more information during the migration or even after it.

In the description to this lesson, you will find a non-detailed plan that you

for your plan, but feel free to create any kind of plan you like in any kind of

you. When you have more than one application, the first thing you need to

application will be migrated first. I won't recommend migrating all these

I think that making small steps application by application is the proper way of

when you have multiple applications. In our case, applications are small, so

probably will be short and quite easy to execute. The only problem that I see

of applications is that probably it will take more time than migrating one big

because you're migrating one by one and the whole process might be long. So

team and multiple small applications, the biggest problem of migration from the

team is that team will be completely focused on migrating. So no new features,

be merged during that time. And when you have multiple applications, as I said,

long. So if you focus only on migrating, your team will get tired of it. And

case. So I would suggest doing something that I call migration timeboxes. So we

you have one week for migration. And after that, you go back to regular

and then one week of migration and so on. And this approach has some advantages

your team can completely focus on migration tasks during the migration timebox.

You don't need to focus on features, back fixes. All you need to do during this

migrate as many applications as it is possible. You can have multiple attempts

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Masterclasses

Tutorials

Fullstack React with TypeScript