Migration to another platform for a stable web application

Project background – the customer needed an extensive architectural transformation. Migration to another platform on a stable web application was needed. It was necessary to develop a working application on a new platform within this project.

The application itself consists of two main components – the frontend and the backend. Historically, .NET technology on an IIS server is used at the frontend, and the backend runs on Java on a Tomcat server.

The main objective of this project was to migrate from the .NET part on an IIS server to a single technology stack (Java + JavaScript).

The customer wanted to finally receive the following benefits:

Migration to other platforms is in some respects a typical task, because problems are usually the same:

However, it must be borne in mind that although the problems are the same, the solution in each case is absolutely individual.

In our case, the customer initially did not know whether it makes sense to invest in this project and needed a detailed assessment of the labor intensity. But how to make an assessment if the project is complex, has a lot of non-trivial solutions and requires a lot of time for initial research?

For these reasons, our project roadmap was as follows:

Let’s consider each stage in detail.

The most important element for tasks related to architectural transformation is well-developed documentation. Since there are many small details in the process, it is critical to include them all in a diagram or document. This allows to process all the required elements within the project and greatly reduces the risk of critical difficulties.

As part of our project, to describe the system, we first made a deployment diagram, which showed all the components of the application.

Also, this diagram showed the interaction of the key components of the application – something without which the application, in principle, cannot function.

After analyzing all the files and components, both major and minor, a sequence diagram was drawn up. This diagram shows how data is exchanged between the frontend and the backend. This made it possible to determine the key functionality of all elements and evaluate possible ways

When we have a sufficiently detailed description of the current situation, we can proceed to work out the concept of solutions. It is very good to have several possible options at this stage for achieving the goal. This allows taking a broader look at the problem and choose the best solution based on all the influencing factors.

Based on the analysis of system current state, the team proposed the following options:

Option No. 3 was chosen as the best one, since in this case the estimated labor intensity and risks were minimal. The result of the work at this stage was the creation of deployment diagrams and the sequence of the future application.

We have a contradiction. We need to make a decision – whether to implement the project or not. The decision is made, among other things, taking into account the project complexity. But since the project has a very high degree of uncertainty, it is not clear how to deal with the risk that the labor intensity will greatly exceed the declared deadlines.

In a normal situation, we would allocate time to assessment, evaluate the task, and then make a decision. However, in the case of migration tasks, this cannot be done. To be more precise, the assessment process may be too superficial and then the risks of missing the deadlines will be very high. One can treat the assessment process as a separate small project. This will allow for a deeper qualitative assessment of labor intensity and risks minimization. But such an assessment is certainly more laborious.

As part of our project, we took another path. And the first question that we had – how long will it take to carry out a deep assessment of the project? To answer this question, we applied the Assessment of Assessments method.

The entire project is deeply decomposed. In our case, the work on the project was divided into 63 tasks and 14 sections. The developer had to give an assessment for each section – how much time it would take him to assess the time needed to complete the work on it. That is, to assess the assessment.

The result of this detailed decomposition gave us a fairly accurate estimate of the time we need to plan and evaluate the work related to migrating from an IIS server to Apache. That is, this is only the time that we need to assess the work on the transition and create a work plan. Ultimately, the assessment of the assessment took approximately 25% of the time needed for the entire work. About 25% was spent on the assessment. So, the customer received decision points for the research project, which made it possible to greatly increase the project predictability level.

The customer was satisfied with this result and approved the conduct of research work to assess the complexity of the project itself.

When assessing the project complexity, it was important to show that we not only assess the project, but are also ready to prove the concept we chose. Therefore, as part of these works, we made a prototype that showed the fundamental performance of the solution we chose.

So, as a result we provided the customer with a study containing an estimate of time and showed a prototype with basic functionality.

The customer was satisfied with the prototype and estimation. The next step was to bring the prototype to a fully functional state so that it could replace the current frontend server on IIS.

At this stage we began to refine the prototype. Support for key components was added to it, and a prototype that was intended to replace a working frontend server on IIS for all key functions was finally demonstrated.

Since the application was covered with many GUI autotests, the customer approved the acceptance of works after the prototype successfully passed all key GUI autotests.

At this stage, all remaining functionality that was not transferred to the prototype was first defined.

Further work was based on standard development processes:

When a ready solution on a new platform was created, this project was accepted by the customer. The subsequent migration from an existing solution to a new platform in a production environment was already carried out as part of a separate project.

In order to migrate to another platform, it was necessary to conduct a detailed analysis of the current system. The task itself was complex and non-trivial due to very high risks both in terms of delays and in terms of possible problems that could arise during implementation. The customer worried whether it was possible to implement this project within a reasonable time frame with the required quality.

However, our experience in implementing such projects helped us approach the problem in the right way. And the necessary expertise of our engineers made it possible to successfully complete the project.

Stack: jQuery, Ajax, Spring Framework.

Infrastructure: AWS, Bitbucket, CloudWatch, Jenkins.