Is the Complete Rewrite the Best Solution for Project Migration?

Software migration is the process of transferring data and functionality from one operating system to another. It’s a very complicated transfer because many things can go wrong. That’s why it can be a nightmare for many developers. And today we are going to answer the question, is the complete rewrite the best solution for project migration? And how to plan this migration carefully.

If you think that a complete rewrite will bring you the best quality product after you migrate, this article will bring some facts to reconsider. But before we begin, let’s figure out the main terms we are going to use.

What Is Project Migration?

When we say project migration, usually we mean the process of transferring from one operating environment to another. It can be applied to hardware as well as software upgrading. Sometimes the term software migration can mean just changing installed applications and data between one piece of hardware and another.

Different Migration Types:

• Data migration. Passing the data from one data storage system to another data format and systems.
• Application migration. Changing an application program and moving from one environment to another.
• Cloud migration. Transfer of functionality, data and all business elements from computers to the cloud, or moving them from one cloud environment to another.
• Software migration. Moving from the programs used to operate computers to the new operating system.
• Content migration. Transfer of information that was stored on one content management system into a new upgraded system.
• System migration. The transfer of business IT resources to another hardware infrastructure or software platform.
• Digital migration. Changing the broadcasting services to another technology with the help of digital-based networks.
• IT infrastructure migration. Changing of all necessary IT assets from one environment to another.
• Operating system migration. The moving an OS (Windows, OSX, etc.) or the main hard disk and to a virtual machine.

There exist many types of software migration and all of them may require different tools to assist.

Common Reasons for Project Migration

Before deciding to plan and execute a system migration, you need to understand the main reasons and look at the problem from different perspectives.

Actually, the reasons for project migration in most cases are narrowed down due to the need for the update which is unavailable with the current projects technologies, integrations and even software.

Migrations are usually done to improve efficiency or bring the applications from a legacy system into a current one. Sometimes businesses want to virtualize their software. Honestly, hosting programs in separate environments for sandboxing at runtime is not an appropriate option for 2019.

There are many things that can go wrong. So, you need to remember some of the main rules before you decide to migrate your project:

• Establish the project’s goals for each phase for each review.
• Create a team of technical experts. Find people who can help with each part of the migration and put them in charge of writing programs to clean the data and knowing where everything is stored.
• Make backups of your data. For software, take inventory on each action and function, how it works with its databases, what it’s compatible and what is not.
• Consider all possible risks. Calculate all potential costs and other issues.
• Set time, and financial requirements. Collect all the information to understand the real timing and checkpoints of the migration process.
• Organize the project management system for all stages. Build a common project management system for everyone to see the progress, of the migration process.
• Make the migration in small phases.  The migration process should be performed and documented after every step.
• Test all migration cases after each phase. Document the result after each step. That’s how you can find the problem at the early stage.
• Work with the results. Record final results, and compare them with your initial goals.

Don’t forget to implement smart innovations to grow your project! The innovations we use in software development today can change our business in the future. All the online digital business products globally.

Two Main Migration Approaches: Complete Rewrite and Gradual Migration

To reuse code is usually hard. The developers tend to write their own functions because it’s easier than trying to understand how the previous functions worked. But! When it comes to the new project that seems to remind the previous one, the experienced developer tends to reconsider his idea of writing absolutely new code. Why should you do this? The old code has been working perfectly. The great work has been done, many tests have been run, many bugs have been found. Refusing to use your code and starting from scratch seems to be illogical. Here comes the approach of gradual migration. Also, gradual migration is the most appropriate way when it comes to huge projects that demand a lot of integrations and functions to be supported 24/7.

As for developers who decide to completely rewrite the code and choose to start the project from the blank page, they have their reasons as well. It’s important to take in mind that when you start, there is no prooves that you will do a better job than you did the first time. First of all, you may not work with the same programming team, so your experience will definitely be different. Probably you will get the old mistakes again as well as the new ones. Usually, devs choose to completely rewrite the projects when this project is small and the process will take a finite amount of time since all pitfalls are considered from the beginning.

Cloud Migrations?

If you chose the difficult way of cloud migration, you should be prepared to face some of these challenges:

1. You will need a lot of resources. Money, people, time, testing resources – all should be organized in a sufficient amount.
2. It’s better to make as few changes as possible before you’re moving a big and complex platform into the cloud.
3. After the whole process of migration, the platform you built has to be tested by the clients and must function in the same way as it did before.
4. It can be hard at the beginning to explain to the team how the migration will add some value for the user but don’t give up.
5. Rebuilding a platform in the cloud results in the use of infrastructure and automation technology you need to use.
6. Don’t think that the project is done the moment the platform is switched on and is used by the customers.

If getting rid of the hassle of configuring servers is your goal, Google Cloud has a number of services that offer various amounts of freedom from things like needing a root password or even using a command line at all. Starting with the Google App Engine in 2008, Google has been slowly adding different ‘serverless’ options with various combinations of messaging and data transparency. Compare the new AWS vs. Google Cloud vs. Microsoft Azure and find out what they have in common and what are their main differences.

Keep in mind that a project manager is a person responsible for the overall migration success. However, the list of the people who are also responsible for your project migration can be found here.

Complete Rewrite Pros and Cons. When It’s Better to Use This Approach?

When you are choosing a complete rewrite, be aware of the pros and cons of this approach.

• It is never just a re-write.
• There is much more to it than what you see at first sight:
  – The old app is up and running while you are rewriting your application, so possibly you can miss new customers and your old customers can be irritated with the process.
  – You never account for all new features that you have to implement in the new application.
  – A new application means new bugs that are hard to catch and are hard to test gradually.
  – You put this application as a whole for the users to test.
• Web components can work outside of Web Components project

There are more developer cases that prove that the strategy of a rewriting from scratch resulted in chaos, and some developers tend to consider this strategy unsuccessful. But if it already happened and everyone on the project is finally past the shock of the need to write off, the rewrite is quite a tempting process.

Gradual Migration’s Pros and Cons. When Gradual Migration Works Best?

The complete rewrite can bring us much closer to the ideal state of migration, but it’s just not suitable for the projects larger than something very small. If your company owns medium-sized projects, you need to consider gradual migration.

The essence of this kind of migration is related to two technologies, the first of which is microservices. It’s the way of architecting your application in such a way that you have only one container to solve one particular problem. Then all containers are connected to each other. This network is called services, that’s why all this architecture is called micro-services.

The service has to be:

• small in size;
• connected by context;
• built and released with automated processes;
• autonomously developed; and
• independently deployable.

To the advantages of gradual migration we can definitely relate the following things:

• The faster project’s bootstrapping using components from different projects.
• Faster release-cycle for a core feature.
• This allows you to do free-agnostic hiring decisions, you don’t need to find people who will primarily work for your project.

Are Microservices and Web Components Here to Help with the Migration?

A microservices architecture decouples individual components of a service, basically, each component becomes an application of its own. All microservices are connected using defined APIs, making it possible to have autonomous teams work on individual pieces of the application, mostly without breaking each other’s functionality.

The monolithic application, typically, can be split into the layers of presentation, business logic, and data access layer. This is the minimum number of components an average enterprise application consists of. At least three different types of components:

• Presentation layer – Components that handle HTTP requests and implement either a (REST) API or an
  HTML-based web UI.
• Business logic layer – Components are the core of the application where business rules are implemented.
• Data-access layer – Components having access to infrastructure components such as databases and message brokers.

As Ruby on Rails development agency, we envision several Ruby on Rails microservices. They all are slightly different from a technical point of view:

• Ruby on Rails app without database to provide views for order and checkout process.
• Usual Ruby on Rails application for back-office and back-offices of partners.
• Ruby on Rails application without views and database as backend for mobile apps.
• Ruby on rails API-only application for core database.
• Ruby on rails API-proxy application without database to integrate with third-party systems, .e.g CRM, sales partners, etc.

The first step in graduate migration is to identify your microservices. If your current framework supports components that you used before, then you probably can go forward. These components can now work as services as well. If you don’t have these components, you need to split your application into small blocks. Once you have structured your application, the next steps are:

• Allow host-to-alien access.
• Write an alien component.
• Write a web component.
• Import alien into a web component.
• Replace the host component with a web component.

In such a way you can get the gradual migration process without all the mess that usually happens during this process. We recommend reading the detailed stories of migration composed by Denys Mishunov, where he describes his experience of the gradual migration process.

If we speak about web components, they are getting more and more involvement in the process of frontend development nowadays. Because web component interface is standard, web components implemented using different libraries can be mixed on the same page. This helps future-proof your applications when you update your tech stack or migrate your project. Instead of a huge change between one framework to another, where you replace all of your components, you can update your components one at a time.

Web components consist of three separate technologies that are used together:

1. Custom Elements. Quite simply, these are fully-valid HTML elements with custom templates, behaviors and tag names.
2. Shadow DOM. Capable of isolating CSS and JavaScript.
3. HTML templates. User-defined templates in HTML that aren’t rendered until called upon.

Is the Complete Rewrite the Best Solution for Project Migration?

There is no simple answer to this question, but we’re here to help! Since the question of migration largely depends on your tech specifications and project size we advice you to go through a discovery session with us. Because Syndicode has already helped lots of projects to migrate!
However, we’re available for any kind of custom development and team extension whether you’d like to migrate your project gradually or completely rewrite!

Syndicode is here in custom software development since 2014. We provide complex custom software development services for different industries. Basically, talking about custom software development in terms of project migration we offer the next services:

• Develop software from scratch – completely rewrite what you currently have;
• Design IT infrastructure architecture;
• Integrate new technologies into a currently running project
  (despite the fact that we haven’t created the original version);
• Run tests to assure the quality of a product;
• Move legacy system to a new platform;
• Provide maintenance.

We know that you want to work with dedicated software teams that have a proven reputation, and that has continued a commitment to providing excellent service. In every stage, our competence can provide you with the assurance of being able to yield the best outcomes. We have one of the most skilled dedicated development teams in Ukraine. So, if you decided to migrate, give us a call!