One of most stressful processes in the life of any IT professional and especially in the level of architect is project migration and complete refactoring. It is needed and many times we see half done and failed attempts of migration with a large number of ruined careers. My view on why that happens I will try to explain in next few lines.

Initial idea. How to know that system migration is needed? Simple measurement is when system architecture and foundation is making system so hard to maintain and business to grow in the same time it makes it more and more expensive demanding more and more spending. But, do not forget that “old fashioned systems” weren’t built with idea and knowledge of current business that is as a live organism: changing and growing. Also, in the modern business we have completely different security knowledge� we didn’t have� before (XSS, etc), demand to have module applications and many other business needs created recently with advancement of technology and especially cloud computing and going mobile. As an architect and or manager, you have to guide business to have good understanding when and why this moment arrived and why investment in refactoring is saving money. You have to spend a lot of time to build trust with business intercepting and resolving of all issues before they reflect on migration process.

Plan. They worst plan you can do in any project planning is to have large switch. That is the last resort because it enormously increases the risk for business failure, data loss, systems outage and rolling back and forth. The most common strategy by IT is to plan a large jump in the distant future and hope that it will never come. The much wiser solution would be to plan gradual transition by using all architectural tricks to help separation of logical components and transition one by one of them. That will provide direct oversight by business owners and reduce risk to much more affordable level.

Roles. Because we are talking of very sensitive process, it is very important to understand roles boundaries between members of the team. In many situations you will have chaos in architecture with� architects running after bugs in code, Data Developers installing and hosting servers, and overused managers doing code and testing strategy in the same time while half of team is free, etc. Management has to understand roles and to keep everyone in the scope of the specific position. Management has to “manage” resources and resources (IT professionals) have to behave as one. These rules are not without exceptions, but every exception has to be picked carefully, understood and well documented.

Implementation. The virtue in migration planning is how to migrate with a good control of migration risk. To do that, I like to use a proxy strategy and separation at� front-end layer. You have to spend some time thinking about smallest steps you can do: smaller they are, lower is the risk. Proxy strategy means that you create front-end SPA-like integration (HTML+JavaScript) circumventing underlying website backend and instead communicating with a proxy API. Proxy API’s job is to send a request to back-end (for not transitioned items) or servicing them or forwarding to the new system if component is already transitioned. One of� larger problems of spaghetti architecture of the� enterprise application is integration through the database. That practice is unacceptable in the modern environment because it makes any scaling harder and creates large number points of possible failure. In the modern� applications performance and clean verified data is a must so any kind of “database fixes” and other tricks are off the table.

Modular design. Modern architectural design demands separation between APIs and all types of front-end (web, mobile apps, import/export components, etc). Having APIs is helping in eliminating of need to have the same code in different places of the same system. Also, vertically, system has to be built in blocks or modular way. Modules as a building components have to be independent as much as they can be. This allows us� to create much cleaner code easier to maintain and scale (both vertically and horizontally).

Final thoughts.� Migration is very demanding process for complete business and it has to be conducted with clear understanding of the process. It is sensitive process, but having A player managers, architects and developers with knowledge and a vision is helping a lot. It doesn’t need to be a large drama for a business and if it is dome right it means reduction of costs and much more responsive system. After transition, architects have to intercept potential risk of need for complete refactoring soon again with building of strategy and creating of solid clean core of the system.

« »