From simple migration to full performance investigation

What started as a simple migration turned into a full performance investigation.

The client needed to migrate from an outdated setup that no longer met their needs to a faster, more stable cloud setup. The application hadn’t been updated in years and was running very old versions of Python, Django, and Django CMS. So while it still “worked,” it had become slow and increasingly difficult to maintain. But the cloud migration exposed something deeper.

The core issue was architectural. The application relied heavily on a plugin-based pattern where every element on a page was implemented as a plugin, and each triggered its own database queries, all executed synchronously.

This resulted in 800 to 1000 queries made per page. In the original on-premises setup, this went largely unnoticed because the application and database lived on the same server, so latency was negligible. However, once the application moved to a proper cloud setup with separate services, the cost of each query increased significantly.

We had to make a choice

• Rewrite the application to better fit cloud architecture
• Replicate the single-server setup in the cloud
• Keep the application architecture and fix the underlying issues

Due to budget and time constraints, a full rewrite was not an option. We chose to keep the architecture and address the inefficiencies, as this was the most viable long-term solution.

We audited the plugins and profiled the application, and discovered several hotspots. These hotspots were plugins responsible for a disproportionate number of queries that could be optimized or removed entirely. One example was a menu extension that, despite generating over 200 queries per page, was never actually used.

After removing unused plugins, updating dependencies, and optimizing query-heavy components, we reduced the query count from approximately 1000 per page to around 300.

The result? The system ran up to 50% faster, operated reliably in a cloud environment, and was better positioned for scaling and new features.

This system was fragile because it made implicit assumptions, such as that the database and application would always be on the same server. When those assumptions were tested, the house of cards came tumbling down.

The real test of application stability isn't whether your application works where it is today; it's whether it will keep working if you move or scale.

That's what we do: we make sure your application works not just where it is, but wherever it needs to be. If you have an application that needs attention, let's talk.