What the Migration Service Includes

• Intelligent Analysis: Generation of a detailed knowledge graph from your legacy code to capture the relationships between procedures, functions, tables, and databases.
• Modern Architecture Design: Establishment of a new microservices architecture, including APIs.
• Automated Backend Code Generation: Implementation of backend in Spring Boot, covering controllers, services, entities, and repositories. Other backend technologies can be requested on demand.
• Frontend Design and Generation: Creation of React-based user interfaces that reflect the screens and interactions of the original application. Other frontend technologies can be requested on demand.
• Continuous Human Validation: Expert-led reviews, adjustments, and validations with our Client throughout the migration process.
• AI-Assisted Testing: Automated generation and execution of unit tests. Execution of functional tests to ensure accurate replication of functionality.

Additionally, our graph structure can identify dead source code and thus avoid migrating it.

What the Documentation Service Includes

• Documentation Generation: Generation of detailed technical and functional documentation for your source code.
• Automatic updates on code changes: Optionally, we can connect to your repository and automatically update the documentation when code changes.
• Access to Virtual Agent: Optionally, you can use our virtual agent, Barbara, which can answer technical and functional questions about your source code by traversing the graph where we represent each part of your software and its connections. Additionally, we can integrate this agent into your developers' IDE as long as they support MCP (for example, Visual Studio Code or Cursor).

Deliverables

• Migrated code that meets client standards.
• README files and Swagger for APIs.
• Unit tests with at least 80% coverage on average.
• Evidence of unit test results and functional tests (optional).

Additional deliverables can be included at extra cost.

(*) The functional test scripts and data must be provided by the Client. Alternatively, the client can perform these tests and report any issues.

Client Responsibilities

To ensure a smooth migration process, we require clients to:

• Clearly describe technical standards and preferences, including coding conventions, folder structures, library versions, or any other relevant guidelines. The code generated by Codacle will strictly adhere to these standards.
• Provide secure access to their code repositories and test databases.
• Specify delivery preferences. By default, we deliver the migrated code directly to your repositories, but we can adapt to any CI/CD pipeline or implementation process you have, which may influence the overall price.
• In case they require functional testing on our part, provide detailed descriptions of the tests required for each form, including available test data and access to an appropriate test environment.

POCs and Guarantee

Proof of Concept (POC): We do not offer free POCs; however, we guarantee that the migrated code will meet the same functionalities as the original application. In that sense, we are equivalent to the migration services of any traditional Software Factory. That is, we deliver a "turnkey" solution, only with significantly shorter times and costs.

Security

All our processes run on secure networks and computers. Your source code will be stored on these computers, as well as in Microsoft OneDrive folders for the duration of the project. Subsequently, all copies will be removed from our storage.

We will send your code to LLMs in the cloud for processing and conversion. Our use of LLMs is restricted to APIs implemented by Azure, AWS, and Google. In other words, we do not go directly to OpenAI or Anthropic, but use the implementations of Azure and AWS. At the moment, we do not use locally installed open-source LLMs (for example, in your data centers), because in our experience they do not offer enough intelligence for this type of work.

Regarding the authorization and authentication of the migrated application, by default we use your existing scheme. For example, if you have tables with usernames, passwords, and user-allowed access to certain functions in your systems, we will continue to use those tables. However, we can integrate with other methods (such as AD) or even create new ones from scratch for your project, subject to additional cost.

FAQ - Frequently Asked Questions

Can we migrate to stacks other than Spring Boot and React?

Yes, we can adapt the migration target to your desired technology stack for an additional cost.

What happens if additional functionalities need to be added during migration?

Any additional functionality or customization outside the original scope will be quoted separately according to the estimated effort.

Will my code be replicated outside my organization?

Yes, part of our process is that we will need a copy of your code to perform the migration. If you have special needs regarding this point, we can review them. For example, we can implement our tools on servers or virtual desktops within your network and run all our processes from there, although this will require additional effort and cost. The LLM calls necessary for code understanding and conversion will always be through cloud providers (Google, Azure, AWS).

Can you use local LLMs like LLaMa instead of going to the cloud?

We currently do not support local LLMs. The reason is that the quality of the generated code is still significantly better when using frontier LLMs in the cloud.

Do you support continuous integration and deployment pipelines?

Absolutely. We adapt to your existing pipelines and processes, delivering the code accordingly.

What if our application has complex desktop-specific behaviors?

We will evaluate and propose the necessary adaptations, clearly communicating any impact on prices or delivery deadlines.

How long does a typical migration take?

Timelines vary depending on the complexity and size of the application, but you can generally expect:

• 6-8 weeks for setup
• 1 average-sized application (10 screens, 10 database tables) every 3 days
• The project start date will depend on our workload at that time, the typical waiting time will be between 1 and 3 months

It is important to note that this time frame may vary depending on the Client's availability to provide test scenarios, test data, perform their own functional tests, as well as the speed of interaction we can have from the Client's side in any necessary adjustment. In other words, this is our own speed, but we can adapt to yours as needed.

Can we introduce functional improvements to the software?

No, our process migrates the functionalities exactly as they are today, applying the same business logic. For the end user, the look and feel and processes will remain the same (although web-based). However, on the inside, the architecture will be completely renewed and the code will follow the client's and industry best practices. If you need to improve functionality, our recommendation is to first migrate the system as it is and in a second phase, make the necessary changes. We can collaborate in this second phase as a separate proposal.

Can you integrate the migrated system with external sources not used by the current version, such as API portals or web applications?

Not by default, but we can analyze the case and possibly perform the integration at additional cost.