Tips. The migration plan

[00:00 - 00:11] 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's easier to migrate an application.

[00:12 - 00:20] We'll consider a few cases as previously and we'll speak what is important to put in the plan. The migration plan is just a concept.

[00:21 - 00:33] You can implement it in the way you like, it might be a total lease, it might be a wiki page, it doesn't matter. For me, it always has been an instruction or checklist.

[00:34 - 00:48] Making the plan has one huge advantage. 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.

[00:49 - 01:12] And if you ask me, I prefer to spend my time preparing when I'm safe and I'm not blocking any team, then spending my time when I'm stressed and I don't want to block my coworkers and so on. So for me, the biggest advantage of having a migration plan is that you can prepare yourself for action and then you can avoid a lot of unnecessary stress at work.

[01:13 - 01:18] So let's start with one huge application. As we noticed in previous lesson, the codebase size will be the biggest problem .

[01:19 - 01:25] Luckily, we have only one application to migrate. In this case, I'm always suggesting doing a dry run.

[01:26 - 01:49] 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 it works on a brand new branch, then delete both branches and you are prepared for real migration.

[01:50 - 02:17] Because application is huge and if you have multiple teams, you don't want to block anyone, it's worth having a fallback plan. If something happens, I don't know, some process will blow up, something will change and you cannot proceed with migration, it's always good to have a go back plan and unblock everyone, then prepare a new migration plan, solve all the problems and then just try to migrate it again.

[02:18 - 02:40] So in this case, when you have one future application, I understand that it has been created by multiple teams across multiple years, you will have some custom things in your application. So having two plans, migration plan and the go back plan is really nice addition for the migration process.

[02:41 - 05:29] One more important thing, when you have multiple teams, it's very unlikely that all teams will be involved in migration. You should spread information about migration before the migration itself, you can show them the plan, you should update your co-workers during the migration and of course you should summarize for all and you should pass all necessary information after the migration. And there's one more tip that I want to share with you, if you work with big applications with multiple teams, as developers we tend to share too many technical stuff, because we think it's awesome, we are passionate about it. And in the early stages of migration, it's usually better to share only the most important information, just not to overwhelm everyone 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 can use as a skeleton for your plan, but feel free to create any kind of plan you like in any kind of form that works for you. When you have more than one application, the first thing you need to decide is which application will be migrated first. I won't recommend migrating all these applications at the same time, I think that making small steps application by application is the proper way of migrating when you have multiple applications. In our case, applications are small, so the migration plan probably will be short and quite easy to execute. The only problem that I see when you have dozens of applications is that probably it will take more time than migrating one big application, because you're migrating one by one and the whole process might be long. So when you have one small team and multiple small applications, the biggest problem of migration from the point of view of team is that team will be completely focused on migrating. So no new features, no back fixes will be merged during that time. And when you have multiple applications, as I said, it might be quite long. So if you focus only on migrating, your team will get tired of it. And usually it's not a good case. So I would suggest doing something that I call migration timeboxes. So we can plan that you have one week for migration. And after that, you go back to regular standard work for two weeks, and then one week of migration and so on. And this approach has some advantages . So first of all, your team can completely focus on migration tasks during the migration timebox.

[05:30 - 05:44] It has been planned. You don't need to focus on features, back fixes. All you need to do during this one week is to migrate as many applications as it is possible. You can have multiple attempts in case of problems.

[05:45 - 06:47] So for example, something happened and you cannot complete the migration. So after migration timebox and you can rethink the whole process, you can find what was the problem. And then in next migration timebox, you can try again. So by definition, you can have multiple attempts, which is good. And in my opinion, it allows you to take small steps and learn on the way, which is very important for programming approach. And I think it works for most of people. And what is the most important? It prevents your team from being tired of nonstop migration. And of course, the biggest disadvantage of timeboxes is that it makes the whole process even longer. What is nice extraction of libraries in this case can be done during the migration process. When you have multiple teams and multiple small applications, you have basically two options. One of the teams will migrate all applications or each team will migrate applications they maintain.

[06:48 - 07:11] And in my opinion, both scenarios are okay and will work. Just take care of your teams, don't let them be tired of work. Just be sure that they are not working more than they should. And again, if you want to check a rough big picture plan for this case, just check the details in the description to this lesson. All right, so the case for multiple big applications is similar to multiple small applications.

[07:12 - 09:38] The only difference is that it will need more work before, more work during the migration, and probably more work after the migration. But all decisions, the whole process will be very similar to multiple small applications. And of course, it will be much more difficult to execute. When you have one small application, the migration is not a problem just use automatic migration, and you'll be happy of results after a few minutes. If automatic migration is not working for you, it's quite easy to migrate it manually. So if you don't have a lot of time for preparing a migration plan, and if I were forced to choose only one of the most important tips or methods from this lesson, I would say that dry run is probably the most important thing . It is engaging you to check in practice how the migration will look like, and what kind of problems will appear during the migration. For me, the main goal of the dry run is to have at least a partially working application. You don't need to make a fully working version of your application . If something is not working, you can come on the code, you can even delete it, just write it out that you need to fix it before the migration and continue with the dry run method. So maybe after the dry run, not everything will work, but at least you will have an overview on the whole process, and you will have all these points saying, I need to fix x, y, z before I start the migration. My plans usually contain a detailed description of all comments and all code changes that I need to introduce to my repo during the migration. And I like to have it very detailed just to be sure that I can repeat my steps from the dry run. And in my opinion, another aspect that is equally important is that dry run gives you a psychological comfort. You can reduce stress by just practicing the migration, and it's not different from any other skills that you can practice in real life , just to feel comfortable with your work. In the next lesson, we'll speak about target architecture. We'll speak about features of Nx that will help you to set some constraints, just to stick as much as you can to the architecture that you want to have.