2. "Lift and shift" breaks more than it saves
Moving applications to the cloud without re-architecting seems faster. It almost never is. A retail client moved their inventory management system to AWS without mapping its dependencies on the point-of-sale system. The result was a two-day outage during peak shopping season.
Every application has hidden dependencies — on shared databases, file systems, internal APIs, scheduled jobs. You need a dependency map before you move anything. Not after.
3. Budgets need to account for what happens after migration
The upfront migration cost is maybe 30-40% of the total. Ongoing expenses — data transfer fees, storage scaling, monitoring infrastructure, staff training — catch organizations off guard.
One project we inherited had budgeted $200K for migration. Actual first-year cost including operations was closer to $550K. They hadn't accounted for data egress charges, which alone ran $8K/month.
Build your budget model around 3-year total cost of ownership, not migration project cost alone.
4. Test like you mean it
"It works in staging" is not a testing strategy. Before any production cutover, you need:
- Functional testing — does every feature work as expected?
- Load testing — can it handle real traffic volumes, not just average traffic?
- Failover testing — what happens when a region goes down?
- Security testing — penetration tests against the cloud configuration.
We run all four in an environment that mirrors production, including data volumes. It adds 2-3 weeks to the timeline. Every single time, it catches something that would have caused an outage.
5. Compliance is not something you "add later"
A European client of ours skipped GDPR compliance verification during their migration. Six months later, they received a six-figure fine. The data residency requirements hadn't been checked — personal data was being stored in a US region.
If you operate in healthcare (HIPAA), finance (PCI DSS, SOX), or handle EU personal data (GDPR), verify compliance on your target cloud configuration before migrating. Not after.
From our work: cloud systems under national load
Two of our projects show these practices in production. Check2Fly, Israel's COVID-era border system, went from kickoff to every airport and border crossing in 90 days. Its cloud infrastructure added capacity in real time when several international flights landed at once, and it held a 15-minute processing SLA with 99.999% uptime. Security was part of every sprint from day one, and the system had zero security incidents across millions of health records.
Shiri, Israel's national music streaming app, runs on an auto-scaling backend we designed for launch-day surges. It reached 600,000 users and #1 in both app stores, with zero downtime.
When the migration runs on Kubernetes
Kubernetes automates deploying, scaling and managing containers across AWS, Azure and Google Cloud. It is powerful and hard to operate, and a misconfigured cluster is worse than none. When we rescue a failed Kubernetes rollout, we usually find three problems:
- Security misconfigurations. Default settings leave clusters exposed. Configure network policies, RBAC and pod security standards from day one.
- Resource sprawl. Teams create namespaces without limits, and the cloud bill spikes.
- Monitoring gaps. Kubernetes produces a flood of telemetry. Without observability tooling such as Prometheus and Grafana, or a managed equivalent, problems stay hidden until they cause outages.
Stateless services move to Kubernetes easily. For stateful components such as databases and message queues, we usually keep them on managed cloud services and move the application logic to the cluster.
Frequently asked questions
Is Kubernetes worth the complexity for a mid-size company?
It depends on the workload. With fewer than five services and predictable traffic, a managed container service such as AWS ECS or Azure Container Apps is often simpler. Past 10-15 services with variable load, Kubernetes starts to pay for itself.
What's the most common reason cloud migrations fail?
Poor dependency mapping. Organizations underestimate how interconnected their systems are. Moving one piece without understanding its connections to others causes cascading failures.
How do you rescue a migration that's already stalled?
We start with a 2-week audit: catalog what's been migrated, what hasn't, where the blockers are. Then we create a revised migration plan with proper dependency mapping, testing gates, and rollback procedures.
Is it ever better to start the migration over from scratch?
Sometimes, yes. If the existing cloud architecture has fundamental security or design flaws, fixing them in place can take longer than a clean re-implementation. We've done both.
If your migration is off track and you need a second opinion, we've likely seen the problem before. Let's talk.
