How can you update legacy code for new operating systems?

To update legacy code for new operating systems, identify deprecated functions and APIs, replace them with current equivalents, address compatibility issues, and leverage modern development tools and practices. Additionally, refactor code to adhere to updated coding standards and conduct thorough testing to ensure compatibility and functionality on the new operating system.

Steps to consider are as follows; 1. Understand the legacy code 2. Research the new operating system 3. Identify compatibility issues 4. Develop a plan: Create a comprehensive plan for updating the code. This should include identifying specific areas that need modification, estimating the effort required, creating a timeline, and defining milestones for the update process. 5. Refactor and modify the code 6. Test thoroughly 7. Address any new security considerations 8. Document changes 9. Iterative improvements Remember, updating legacy code can be a complex task and may require collaboration with other team members, as well as thorough testing and quality assurance processes.

If management starts from asking you for a fixed date / deadline for the entire upgrade before you were even granted access to all necessary components to estimate the cost+effort, you will have a bad time. Last thing you want to say is "yes we can". List and share all the blockers to everyone, including your recent mail to Santa :)

é fundamental que para o código legado ele seja organizado, compreendido e analisado em partes para que o todo funcione perfeitamente.

Updating legacy code requires assessing its age, language, framework, and compatibility with new operating systems. Evaluate the code's documentation, testing, dependencies, and underlying assumptions. Allocate resources wisely, considering time, manpower, and costs. Prioritize tasks based on critical needs and benefits. Develop a realistic timeline and budget, considering potential risks and mitigation strategies. Effective communication with stakeholders is also crucial for a successful update.

Es muy útil revisar los documentos y las web del fabricante del sistema operativo, la mayoría de las dudas que surgen se pueden resolver leyendo los diferentes artículos de la web del fabricante. Apoyarse también con los diferentes foros específicos donde muchas veces, el resto de usuarios también se han topado con los mismos problemas.

One thing I have found useful that it does not hurt when you go through new OS documentation. It keeps you up to date with new trends and sometimes gives you better insight on application behaviour from resource utilisation view standpoint.

In OS/Application Modernization, strategies differ based on asset type and goals. Greenfield projects (with source code) rely on IDEs for testing and debugging, while brownfield projects (without source code) depend on manual runtime testing. Cloud tools like Evolute Migrate or AWS/Google/Azure Migrate expedite modernization, potentially speeding up the process by up to 10x. OS vendors offer runtime tools for compatibility assessment in new operating systems, aiding both greenfield and brownfield modernization. The choice between containerization and code rewriting in Application Modernization hinges on specific business and technical needs, allowing a customized approach to each project.

Uma coisa que achei útil e a manuten??o continua, dessa forma manter o código atualizado a medida que novas vers?es do sistema operacional forem lan?adas pode garantir a compatibilidade contínua. Incorpore também testes exaustivos testando o código em vários ambientes do novo sistema operacional para garantir que funcione corretamente.

Modern tools play a significant role in legacy code migration. Modern tools help in auto code conversion in re-engineering methods such as reverse engineering, forward engineering, etc. Automated testing tools help ensure that modifications to the existing codebase do not inadvertently introduce new issues or break existing functionality.

Adopting an analysis and design-based perspective is often a superior practice compared to source-to-source code migration when dealing with legacy systems. It allows for a more holistic understanding and targeted improvements.

Once you have reverse engineered what exactly your legacy code does. Choose a new technology and use it to implement the legacy logic. Take time and plan out optimization. Back when that legacy code was written things were done in different ways. Modern architecture may greatly simplify the way data is processed and moved around.

Tras las pruebas iniciales donde se revisa que todo funciona de manera correcta, es necesaria realizar una batería de pruebas completa de todo el entorno. Para ello, apoyándonos en el documento realizado en el paso 1 (análisis) se prueba y testea todo el desarrollo. Como recomendación, tras las pruebas iniciales del equipo de desarrollo, las pruebas siguientes deberían de realizarlo otro equipo externo al equipo de desarrollo para comprobar que funciona todo correctamente sin estar sugestionado por el conocimiento del código.

To ensure that the modernized software offers the same or improved functional depth as the legacy system, it is essential to conduct a thorough analysis, comprehend the intricacies, and draw meaningful comparisons during the test strategy.

A new approach is emerging that leverages GenAI. * First, have multiple GenAI tools read your legacy code and "explain" it back to your Eng team. * Next, leverage (again, multiple) GenAI tools to ingest your Eng curated explanation and the legacy code and have it re-write the "intent" of the code in a new language/platform/OS paradigm. * Leverage alternative GenAI tools to review and modify the GenAI generated code. * Finally, leverage your Eng Teams to review & complete the new code. A 50% increase in Eng performance has been observed when automating & leveraging this approach.

- In my experience and given the complexity of legacy code and most of the times with no documentation, all the previous perspectives rely on a work of reverse engineering. - For this purpose, the role of the architect is essential. First, to represent the elements of the legacy code (libraries , services, APIs, databases, other) in a coherent and useful instrument to clear address the communication to different stakeholders. Secondly, to plan the future architecture and the transformation plan to bring the legacy code to a future target system (target architecture).

I'd be very cautious in involving AI in code reviews of any type but especially for SQL. As just one example, I've asked multiple AI platforms how to properly combine a DATE datatype column and a TIME datatype column to a column any temporal datatype. To date, most of them have been able to do it without suffering the "hidden failure" of rounding up. While the rounding is less than 3 milliseconds, that can cause you to round up to the next second, minute, hour, day, week (inherently), month, and even year. People ask me "Well! How often does that happen"? My answer is that if it happens even just once, it's wrong. And, it doesn't actually have to be an occurrence in your database... the issue is that it could become one.

Con herramientas o sin ellas, no pongas a Juniors a hacer el trabajo de Seniors y viceversa, es mejor tener un equipo multidisciplinar donde cada uno aporte su valor y experiencia.

A the end of the project time you will be pushed to implement something on preprod/prod without testing. CYA and take such orders in written form.