added migration pages

Signed-off-by: bidi <bidi@apidemia.com>

Author: bidi47

docs/book/v1/introduction.md

@@ -4,3 +4,10 @@ The principle of a Headless Platform is to decouple the User Interface (frontend
 The responses from the platform are then used by another system, such as a website or mobile app.
 
 ![Headless Platform](https://docs.dotkernel.org/img/headless-platform/api-comms4.png)
+
+Its design leads to a great deal of versatility in the setup and configuration.
+Here are some of the advantages of the Headless Platform:
+
+- The ability to have multiple frontends, each targeted to various end-users, like desktop vs mobile, iOS vs Android etc. 
+- Different frontends (websites) for various niches (younger vs older users) and countries (including localization).
+- Ability to customise separate frontends in terms of design, as well as available features.

docs/book/v1/migration/full-rewrite.md

@@ -0,0 +1,33 @@
+# Full Rewrite or Big Bang Rewrite
+
+A full rewrite is a software migration strategy that implies completely rebuilding the system from scratch in the new architecture or technology.
+
+## How It Works
+
+- You keep the old application in use, as-is.
+- In parallel, you work with the development team to build a new version of the application in the target environment.
+- Once the new application is complete and tested, you redirect all execution to the new application.
+- You decommission the old application.
+
+## Pluses
+
+There are several advantages to this approach:
+
+- Blank slate – No technical debt is carried over to the new application.
+- Optimal architecture – You can code the new application without worrying about legacy code or outdated design patterns.
+- Better maintainability and security – The new code can follow modern best practices which may be incompatible with the old code.
+
+## Minuses
+
+The disadvantages often weigh heavy against choosing this approach:
+
+- High risk – Your release must work on the first try, there’s no partial rollback.
+- Long timeline – There is no immediate user value during development.
+- Expensive – Building a second product in parallel may prove to be just as costly as the original product.
+- Feature drift – Since the old application is still running, any updates performed on it may cause further delay on the development of the new one and greater mismatching of business logic.
+
+## Conclusion
+
+Performing a full rewrite is no easy choice.
+More often than not, the costs are the main reason you would not choose this migration strategy.
+You may find yourself delaying its implementation until you are forced to do so by circumstance.

docs/book/v1/migration/introduction.md

@@ -0,0 +1,17 @@
+# Migrations
+
+When we talk about **migration**, we primarily refer to the **transfer of functionality** (the codebase) from one platform to another, more often from an older architecture like MVC, to a modern one like middleware.
+Still, a complex platform migration may include:
+
+- Replatforming - e.g. from on-premises to the cloud.
+- Refactoring - to improve readability, maintainability, and efficiency.
+- Database or storage migration - to improve execution time and/or security.
+
+The **migration of the software codebase** is the process of moving a software system's source code **to another environment**, which can involve:
+
+- Updating to a newer version of a language or framework.
+- Changing the infrastructure e.g. moving from SQL to NoSQL databases.
+- Replacing designs for security and compliance requirements.
+
+The process ensures that software is kept functional, compatible, and secure as the technology evolves.
+It is also the perfect opportunity to implement modern design patterns recommended by the development community.

docs/book/v1/migration/modular-refactoring.md

@@ -0,0 +1,35 @@
+# Modular Refactoring
+
+The Modular Refactoring is a migration strategy where you break a large, tightly coupled codebase into smaller, independent modules.
+Once the modules are defined, you begin the migration to the new architecture.
+
+## How It Works
+
+- Identify logical boundaries in the business logic.
+Search for sections of code that can function independently.
+- Decouple dependencies.
+Refactor code to reduce direct cross-module calls, often introducing interfaces or APIs for communication.
+- Isolate each module.
+Ensure each module can be built, tested, and deployed separately.
+- Migrate module-by-module.
+Move one module at a time to the new architecture, integrate it back into the system, and test its functionality before moving on.
+
+## Pluses
+
+- Controlled scope – Each migration step is focused on one module.
+- Improved maintainability – As the migration progresses, the system becomes cleaner and more modular.
+- Enables parallel work – You can assign different development teams to migrate different modules at the same time.
+- Lower risk – If a migration fails, only one part of the system is affected.
+
+## Minuses
+
+- Refactoring cost – Breaking a monolith into modules takes time and effort.
+- Possible temporary slowdown – You may need to allocate resources from new feature development to the refactoring effort.
+- Requires strong design discipline – You need to carefully plan modules to avoid repeated rework.
+
+## Conclusion
+
+Modular Refactoring implies a great deal of preparation (proportional to the complexity of the application) before the migration takes place.
+You take e.g. the existing monolith and reorganize it into clearly defined modules, while in the same repository.
+You can the extract the modules into new repositories or move them into microservices, and create interfaces between the old and the new code.
+For the actual code migration, you can opt for the Strangler Fig Pattern. 

docs/book/v1/migration/strangler-fig.md

@@ -0,0 +1,27 @@
+# Strangler Fig Pattern or Incremental Migration
+
+The Strangler Fig Pattern is a software migration strategy that implies gradually replacing parts of the old application with new components until the old application is not needed any more.
+
+## How It Works
+
+- Wrap the old application with a routing layer that enables you to selectively redirect incoming requests to either the old code or to new code.
+- Choose an existing feature or service and build it in the new architecture.
+This applies to new features, as well.
+- Replace old features as they are ready to be deployed.
+After development and testing is complete on the new code, reroute traffic for that feature or service to the new code.
+- Decommission the old application.
+Once all features and/or services are migrated, you can shut down the legacy code completely.
+
+## Pluses
+
+- Lower risk – Each change is small, and thus easier to manage and test.
+- Continuous delivery – Users and stakeholders see improvements throughout the development process.
+- Easier rollback – If the new code doesn't work as intended, reroute traffic back to the old code until the new one is revised.
+- Better learning – You discover and fix problems early, adapt your plan more dynamically, and understand the business logic better.
+
+## Conclusion
+
+The Strangler Fig Pattern is the recommended way to go for legacy applications, especially complex ones where a full rewrite would take years and/or millions of dollars.
+You mitigate downtime and risk by handling small, easily manageable sections of code at any given time.
+One restriction for this pattern is that you need to be able to intercept requests and redirect execution.
+The development team can be smaller (since you isolate sections of code you work on) and the development schedule is more adaptable (you can stop at any time because the old application is always there).