WordPress Migration from OVH to AWS
The Revista GODOT website used to go down every day. Now it doesn't go down, and it costs 30% less.
30 % in server savings, with better performance than before
Custom software
System Modernization
You have a system that works, but nobody wants to touch it. Maintaining it costs more every time, and changing it is a risk. We modernise it in stages: the current system keeps running while the new one gradually replaces it.
- System review
- Staged plan
- Replacement in stages
Who it is for
It is for you if…
- Companies with a system developed years ago that is still in use and that nobody wants to touch.
- Companies whose system depends on components that nobody fixes or updates anymore. Each year it costs more to maintain.
- Companies that want to stop maintaining their own server and pay only for what they use.
It is not for you if…
- Anyone who wants to rewrite everything from scratch and switch off the old system on a set day. This is the riskiest route and we don’t recommend it.
- Small systems that are better replaced with an off-the-shelf product.
What you get
- Review of the current system
What it does, what it depends on, how much it is used and what security measures it needs. Which parts stand to gain most from the change.
- Staged plan
What is migrated first, in what order, and how the old and new systems coexist.
- New parts running
Each migrated part keeps working, with its database adapted and monitored.
- Documentation and handover
Diagrams of the before and after, and a user manual. Also a handover session for your team or whoever will maintain the system.
First, understand what you have
Before touching anything, we analyse the system as it is: what it does, what it depends on, how many people use it and where it stores its data. We also identify which parts cause the most problems. From that comes a plan in stages: what changes first and why.
Changing in stages, with the system running
We don’t rewrite it all at once. We move one part at a time, for example invoicing or customer access, and launch it alongside the old system. The old one keeps doing whatever has not yet been migrated. When the last part is migrated, the old system is switched off without anyone noticing.
Security, cost and monitoring
Every new part is built with up-to-date security measures: who can get in and what they can do, access keys stored where they should be, and a log of who did what and when. You only pay for what is used, and we alert you if spending rises. Every new part comes with monitoring.
If your client or the law asks for more
Someone from outside may review your software, and you may know it wouldn’t pass that review today. Renewing it in stages lets you fix first what that review is going to look at. And if you sell to the public administration, its security rules also apply. We explain this on our Custom software page, in the section «If your client or the law asks for more».
What we build it with
Each part we move is converted to serverless functions on AWS, Amazon’s infrastructure. You pay only when it runs, and there is no server switched on permanently. We use languages with official support on Lambda, such as Node.js, Python, Java or Go. If your software is in PHP, it can be kept with a custom support component (a custom runtime) that must be maintained separately. This costs more; we explain it and you decide. Data goes to PostgreSQL (Aurora) or DynamoDB, depending on the case. Every new part comes with monitoring and alerts if spending rises. The code, the server definitions for where it is hosted (infrastructure templates) and the documentation are delivered to your repository. This is where the code is stored with its full history, and it belongs to you.
Glossary
- Legacy system
A system developed years ago that is still in use and that nobody knows well anymore. In the industry it is called a legacy system.
- Third-party components
Parts of the software not developed by your supplier, but by third parties, on which your software depends. If one has a security flaw, so does your software.
- Support
Whoever developed a component keeps fixing its bugs and publishing security updates. Without support, every flaw is left unfixed.
- Security breach
A flaw that could allow someone to access or see what they shouldn't.
- Pay-per-use
You only pay when the system is working. There is no server switched on permanently.
- Rollback
Being able to return to the previous state if something goes wrong, without losing data.
What problems it prevents
What can go wrong and how we prevent it.
- The business stopping during the change
The current system keeps running until the last part is migrated. Every step can be undone.
- The new system inheriting the security flaws of the old one
Each part is rebuilt with up-to-date security measures: access control, well-guarded keys and third-party components reviewed.
- The project never ending
Staged deliveries, each one closed off. Each leaves the system better, even if the project stops.
- Data being lost during migration
The migration is rehearsed on copies, tested and has a planned rollback.
A related case
Frequently asked questions
It depends on the size of the system and its internal complexity. After the review, we give you a staged plan with timelines. The first part is usually the one that solves the most problems.
Yours. The code and documentation are in your name, in the place where your code is stored with its full history.
First, a meeting. Then we send you the quote for the review. With the staged plan, we give you a fixed price for each part.
Not always. If the current language is supported by the tools we use, it is kept. If not, we propose another and explain the cost of each option.