From AWS to Hidora: how to cut your cloud bill by 5x

When a Swiss fintech scale-up contacted us earlier this year, the situation was stark: their AWS bill exceeded CHF 8,000 per month for a web application with a database, a few microservices and a staging environment. For a 25-person company, it had become unsustainable.

Six months later, the same application runs on Hidora Cloud. The monthly bill: approximately CHF 1,600. Performance is identical, even better in some areas. And the data is now hosted in Switzerland.

Here's how this migration unfolded, and why a growing number of Swiss companies are leaving hyperscalers.

The AWS convenience trap

The story is classic and all too familiar. The company started on AWS five years ago, when the technical team had two developers. AWS was the obvious choice: abundant documentation, managed services, automatic scaling. The early days were straightforward and the bill reasonable, a few hundred francs per month.

But over the years, complexity accumulated. An RDS instance here, ElastiCache there, load balancers, CloudFront, Lambda functions for one-off tasks, an ECS cluster for microservices. Each addition seemed logical at the time. Nobody had an overview of total costs.

The wake-up call came when the CFO asked for a detailed cloud bill breakdown. The analysis revealed several problems:

• Over-provisioned resources. EC2 instances ran at an average of 15% CPU utilization but were sized for peak loads that only occurred a few hours per week.
• Unused services. Three development environments had been left running after the developers who used them had left the company.
• Expensive data transfers. Communication between AWS services in different availability zones generated significant transfer fees, a cost that's often invisible.
• No optimization. No reserved instances, no savings plans. Everything was billed at on-demand rates, the most expensive option.

The cost creep pattern

This company's experience is not unique. It follows a pattern we see repeatedly among Swiss SMEs and scale-ups that started on hyperscalers. The trajectory is predictable: a small team picks AWS or GCP because it's the industry default. The initial bill is low, sometimes even covered by startup credits. As the product grows, new services are added organically. Each individual decision makes sense, but nobody tracks the cumulative cost.

By the time the finance team raises the alarm, the architecture has become a sprawl of interconnected services where removing any single component risks breaking others. The switching cost feels prohibitive, which is precisely what keeps companies locked in. This inertia is not a technical problem; it is a business problem. And it compounds over time: the longer you wait, the more entangled the architecture becomes and the more expensive migration appears.

The reality, as this case study demonstrates, is that a well-planned migration is faster and less risky than most companies assume.

Evaluating alternatives

The technical team first attempted to optimize within AWS. They right-sized instances, activated savings plans, removed unused resources. Result: the bill dropped from CHF 8,000 to CHF 6,500. Better, but not enough.

That's when they started looking beyond hyperscalers. Two additional factors accelerated the thinking:

1. Data sovereignty. Their main banking client had begun requiring guarantees about data location. AWS Zurich existed, but the legal question remained complex: data on AWS remains subject to the US Cloud Act, even when hosted in Switzerland.

2. Operational complexity. Managing AWS infrastructure required a DevOps engineer nearly full-time. For a 25-person company, this was disproportionate. The team wanted to refocus on product development.

The migration to Hidora

After an initial free audit with the Hidora team, the migration plan was established within a week. The target architecture was significantly simpler than the AWS setup, without sacrificing resilience.

Weeks 1-2: Environment replication. Hidora infrastructure was configured to replicate the existing architecture: application servers, PostgreSQL database, Redis cache, reverse proxy. The key difference: on Hidora, vertical and horizontal scaling is native and automatic, without requiring a constellation of AWS services.

Week 3: Data migration. Databases were migrated via a real-time replication process. For 48 hours, both environments ran in parallel to validate data consistency.

Week 4: Testing and validation. Load tests were run to confirm that the Hidora infrastructure matched AWS performance. Results met expectations: equivalent response times, even better in some cases thanks to reduced network latency (data staying in Switzerland, closer to end users).

Week 5: Production switchover. The DNS switch was performed on a Saturday evening. Actual downtime: less than 5 minutes. The Hidora team provided 24/7 monitoring for the first week post-migration.

Detailed migration timeline: what happened behind the scenes

The five-week summary above captures the major milestones, but the reality of a cloud migration involves dozens of smaller decisions and tasks that are easy to underestimate. Here is a more granular view of what the team navigated during the process.

Pre-migration (Week 0): Dependency mapping. Before any infrastructure was provisioned, the Hidora team and the client's CTO spent two days mapping every service dependency. This meant cataloguing every API call between microservices, every external integration (payment gateways, email providers, third-party analytics) and every cron job. The result was a dependency graph that revealed three undocumented services still running on AWS Lambda that nobody on the current team had written. Without this mapping exercise, those services would have silently failed after the DNS switch.

Week 3 detail: Handling schema differences. The PostgreSQL migration was not a simple dump-and-restore operation. The client's database had accumulated five years of schema migrations, some of which contained AWS-specific extensions (such as aws_s3 for direct S3 exports from SQL queries). These had to be replaced with standard PostgreSQL functionality before the replication could begin. The Hidora team identified four such dependencies during a dry-run migration and resolved them in advance, preventing what would have been a blocking issue during the live cutover.

Week 4 detail: Load testing methodology. The load tests were not generic benchmarks. The team replayed three weeks of anonymized production traffic against the Hidora environment using a traffic replay tool. This approach tested real-world access patterns, including the irregular spikes caused by batch processing jobs that ran twice daily, rather than synthetic load profiles that might miss edge cases.

Risk mitigation during migration

One concern the CTO raised early in the process was risk. Their application processes financial transactions, and any data loss or extended downtime during migration could have regulatory consequences. The migration plan was designed with multiple safety nets to address this.

Parallel running. Both AWS and Hidora environments processed real traffic simultaneously during a 48-hour validation window. Application logs were compared to confirm identical behaviour. This dual-write approach meant that if any issue had been detected on Hidora, traffic could be routed back to AWS instantly.

Rollback plan. The AWS infrastructure was kept fully operational for 30 days after the switch. DNS TTLs were reduced to 60 seconds before the cutover, allowing near-instant rollback if needed. In practice, the rollback was never triggered.

Data integrity verification. After the database migration, automated scripts compared row counts, checksums and recent transaction records across both environments. This verification caught zero discrepancies, confirming the migration's fidelity.

These precautions added roughly one week to the timeline but provided the confidence the executive team needed to approve the production switch. For any company considering a similar migration, we strongly recommend investing in this validation phase rather than cutting corners to save time.

The economic impact

The numbers speak for themselves:

Over a year, the savings exceed CHF 77,000. That's the equivalent of a junior developer's salary. For a 25-person company, reinvesting this amount in product development has a direct impact on competitiveness.

Why such a price difference?

The question deserves to be asked. How can Hidora deliver the same performance at one-fifth the cost?

Several factors explain the gap:

No "hyperscaler tax." AWS charges a significant premium for its brand, global ecosystem and managed services. For a Swiss company that doesn't need 30 global regions and 200 different services, this premium is unjustified.

Right-sized infrastructure. Hidora dimensions infrastructure based on the client's actual needs, not predefined instance categories. Granular scaling eliminates systematic waste.

No hidden transfer fees. With Hidora, data transfers between services are included. On AWS, every gigabyte crossing an availability zone boundary is billed.

Integrated services. Monitoring, automatic backups, SSL and support are included in the base price. On AWS, each additional layer is a separate paid service.

Lessons learned: what we would do differently

No migration is perfect, and transparency about what could be improved is more valuable than a polished success narrative. Here are the key lessons from this project.

Start the dependency audit earlier. The undocumented Lambda functions discovered during Week 0 could have caused a production incident if the mapping exercise had been skipped or rushed. For future migrations, we now recommend starting the dependency audit two weeks before any infrastructure provisioning begins, giving the team time to investigate surprises without delaying the overall timeline.

Involve the finance team from day one. The CFO was the person who initiated the cost conversation, but they were not included in the migration planning until Week 3. Earlier involvement would have helped set realistic expectations about the transition period where both AWS and Hidora bills run simultaneously, avoiding an uncomfortable board question about a temporarily doubled cloud spend.

Automate the comparison testing. The data integrity verification scripts were written specifically for this migration. We have since turned them into a reusable framework that can be configured for any PostgreSQL-to-PostgreSQL migration, reducing the preparation time for future projects by several days.

Beyond costs: sovereignty regained

Cost reduction was the initial trigger, but the benefits go well beyond.

The company can now guarantee its clients that their financial data is hosted exclusively in Switzerland, in data centers subject to Swiss law. This guarantee unlocked two major contracts with financial institutions that categorically refused AWS for regulatory reasons.

Hidora's ISO 27001 certification also simplifies compliance audits. Rather than having to explain AWS's complex architecture and Cloud Act implications, the company can present a clear and understandable framework to its auditors.

Operational simplicity

The last benefit, often underestimated, is the simplification of day-to-day management. The DevOps engineer who spent 60% of their time managing AWS infrastructure now dedicates 80% of their time to product development. Infrastructure management is shared with the Hidora team, which handles monitoring, security updates, backups and performance optimization.

For Swiss companies that recognize themselves in this situation (a runaway AWS bill, unanswered sovereignty questions, disproportionate operational complexity), migration to a local cloud platform deserves serious consideration. The savings are real, measurable, and immediate.

Curious about what your own migration could look like? Our team offers a free infrastructure audit to evaluate your current setup and estimate potential savings.