programturizmus.hu: Rebuilding a 19-Year-Old Portal on Kubernetes Microservices
programturizmus.hu is one of Hungary's largest tourism portals and ranks among the first results for searches about programmes, tourism, and cultural topics in Hungary. We rebuilt the portal, which launched 19 years ago: we documented how it works from the existing site and database, then built a microservice-based platform running on Kubernetes. Keeping the search rankings was a top priority during the switch, and the rankings did not drop.
The project in numbers
- A database with several million rows across about 100 tables
- Nearly 20,000 programmes stored in the system
- Roughly 200 GB of files migrated
- 3-4 months of specification, then development from August 2024, with the go-live in April 2025
- 10 months in total, from the start of development to the end of the post-launch optimization rounds (May 2025)
- A switchover of almost 12 hours, with the site unavailable for about 2 hours
Where we started
The portal was built on PHP and MySQL, using old versions and without redundancy. One large monolithic application served everything. Overall loading was slow: opening a single programme page could take 6-8 seconds.
- Slow loading: programme pages could take 6-8 seconds to appear
- Monolithic structure: every feature lived in one hard-to-change unit
- Old technologies: development therefore moved slowly
- No redundancy: the system was not fault tolerant
Our collaboration started with a new design: the managing director approached us for it. Because of the old technologies and the complex monolith, development progressed slowly, so we began discussing whether we should take over the portal and rework the whole system.
Why we rethought the whole structure
Together with the managing director, we agreed to write the specification based on the functions visible on the website. The codebase built up over 19 years and the portal's slow loading at the time were reasons not to patch the existing system, but to rethink the structure completely. The new system is therefore not a rewrite of the old code, but a rebuild of how the portal works.
Discovery: we started from how the portal works
In spring 2024, in close cooperation with the managing director, we began the requirements gathering and the specification. Based on the user-facing side, we described how the portal works, which processes it contains, and how they should work. We only needed the database structure to map the stored data onto the functionality we had documented.
We discussed orders and invoicing with the editorial colleagues who handle them every day. Writing the specification took 3-4 months, and the result was a detailed written document that became the blueprint for the new system.
The new architecture
Based on the specification, we split the portal into smaller, independent services, using a domain-driven approach along business functions. The services can be developed and deployed independently of each other, and they run in a Kubernetes environment. Development started in August 2024.
We built on modern JavaScript technologies: Next.js on the front end and Node.js in most services. Depending on the nature of the data, we use both SQL and NoSQL databases. Multi-layer caching helps serve pages quickly.
Data and file migration, testing
The old database had about 100 tables with several million rows and nearly 20,000 programmes, and the files amounted to roughly 200 GB. We transformed the data to fit the new structure and moved the static files into the new system.
Before the live switchover, we ran rehearsal migrations on every element, meaning the database, the files, and the services, in a separate test environment. We tested the database migration in full, and moved a subset of the files to verify that uploading works. Before launch, several members of the editorial team tested the new system.
The switchover
The live switchover was a process of almost 12 hours. Part of it was preparation and part was verification, and the portal itself was unavailable for about 2 hours.
Keeping the search rankings
The portal ranks among the first results for keywords about programmes, tourism, and cultural topics in Hungary, so keeping its rankings was one of the most important goals of the switch. The aim was not to disturb the SEO.
- We kept the URL structure, the metadata, the structured data, and the content.
- We brought in an external SEO partner during development.
- We continuously monitored the SEO structure of the portal under construction against the live site of the time using crawl comparisons, so there were no critical differences.
- After the switchover, we tracked the rankings in Search Console.
The result: the SEO stayed stable and the rankings did not drop.
Results
- The search rankings stayed stable after the switchover.
- The launch (April 2025) was followed by further optimization rounds until May 2025.
- According to Google Core Web Vitals, all three metrics (LCP, INP, CLS) are currently in the green zone, including on mobile.
- The services can be developed independently, so the portal is easier to extend.
One year later: moving the infrastructure
The original hosting infrastructure proved not stable enough: failures of the physical servers caused several outages. We therefore moved the entire infrastructure, meaning the web portal, email, and file storage, to a new provider.
The whole move took about 8 hours, and the actual service downtime was about 2 hours. We scheduled it overnight to disrupt visitors as little as possible.
What this means if you have a similar system
- A system can be rebuilt from a detailed description of how it works, if that description is made carefully and together with the people who use it.
- SEO is a project requirement, not an afterthought: measure and compare before the switchover.
- Rehearsal migrations reduce the risk of the live switchover.
If you would like to know more about how we approach modernizing older systems, read about our Legacy system modernization service.
Key technologies
- Kubernetes: running and scaling the services
- Microservices: domain-driven separation along business functions
- Next.js and Node.js: a modern JavaScript front end and services
- SQL and NoSQL databases: depending on the type of data
- Multi-layer caching: fast page delivery
Facing a similar challenge?
Send us a short description of your system, and we will tell you honestly whether our approach fits.