Company overview
Due to a strict Non-Disclosure Agreement (NDA), we cannot disclose the client’s name. The client is a small European fintech startup with a team of ~30 people, combining product, engineering, and customer support functions.
Business context
The client builds and operates a cloud-based platform for processing financial transactions and managing customer accounts for B2B clients. The engineering and operations teams rely on an Atlassian-based toolchain as their primary workspace for incident management, release coordination, and regulatory change tracking. Because the platform handles sensitive financial data and must meet strict uptime expectations, the stability, security, and auditability of their Atlassian environment are directly tied to business continuity and compliance.
Initially, this platform was deployed as a “temporary” solution on a single physical server running VMware Workstation to quickly set up a working environment. However, as the business grew, this temporary setup quietly evolved into a full production system. It became critical to day-to-day operations yet lacked redundancy or a clear path to scale.
Dependence on a single physical host
The entire Atlassian stack was run on a single server. This created a severe single point of failure: any hardware failure, configuration mistake, or hypervisor issue could bring the whole engineering organization to a halt.
No redundancy or scalability
The system lacked automated backups and true redundancy, resulting in an unacceptably high risk of data loss. Additionally, scalability was capped by the resources of that one machine. The client could not scale horizontally, and any capacity change required manual intervention.
Manual security & networking
Network segmentation and access control were implemented manually and ad hoc rather than using built-in cloud mechanisms. This made the environment difficult to evolve and complicated security audits and compliance efforts.
No clear modernization path
The client needed more than just “a new server.” They wanted to reduce risk while defining a path toward managed cloud services. However, they lacked a clear strategy to achieve this without disrupting the application architecture or their teams’ daily work.
Solutions we implemented
Our strategy: Preserve first, optimize later
Our primary goal was to safely “lift” the Atlassian platform off its fragile VMware host and land it in AWS. We chose a strategy that prioritized stability over immediate reinvention. We aimed to maintain the application model’s familiarity to the client’s team while addressing the fundamental infrastructure limitations that were hindering their progress.
We guided the migration using 3 core principles:
- Replicate, don’t redesign. Instead of forcing a move to managed services on day one, we recreated the existing architecture in AWS. Application nodes, PostgreSQL (Primary + Replica), and NFS storage were migrated to EC2 instances. This reduced the risk of “breaking changes” and shortened the timeline.
- Eliminate single points of failure. We replaced the lone physical server with a resilient network design. We separated the front-end, application, database, and storage tiers, ensuring that a failure in one component wouldn’t ruin the entire system.
- Minimize risk. We rejected the idea of a “big bang” migration. Instead, we used AWS Application Migration Service (MGN) to perform continuous block-level replication, allowing us to treat the final move as a predictable, controlled event.
The target AWS architecture
We transformed the single-host on-premise setup into a robust cloud architecture in the eu-central-1 region.
- Network foundation (VPC): We designed a custom VPC (Address space: 10.0.0.0/16) split into public and private subnets to ensure secure isolation for critical assets.
- Access & security: The on-premise HAProxy was replaced by a managed Application Load Balancer (ALB) in the public subnet. This became the single, secure entry point for all HTTP(S) traffic and health checks.
- Compute & database: The Atlassian application nodes and PostgreSQL database were placed in private subnets, completely shielded from the public internet. While currently running on EC2, this setup provides a seamless upgrade path to Amazon RDS in the future, eliminating the need for another disruptive migration.
- Storage: Our team implemented a shared storage via an EC2-based NFS server. This allowed us to preserve the application’s file-sharing behavior exactly as it was, while setting the stage for a future switch to Amazon EFS.
Modernization roadmap on AWS
After the initial lift‑and‑shift, we proposed a phased roadmap to the client:
To ensure a predictable outcome, we developed a transparent roadmap that validated every stage before proceeding to the next one.
Planning & discovery
We established clarity from day one. In joint workshops with the client’s IT team, we defined the precise tolerance for downtime and mapped the “invisible” web of dependencies – network pathways, DNS records, and configuration quirks.
Building the cloud foundation
Our team prepared the destination environment before mobilizing any data. We constructed a secure Virtual Private Cloud (VPC), organized the subnets for isolation, and configured the necessary IAM roles and Security Groups to ensure the migration tools operated securely.
Silent synchronization (AWS MGN)
We prioritized business continuity, using AWS Application Migration Service (MGN) as the engine of our strategy. By deploying lightweight agents on the source servers, we initiated continuous, block-level replication in the background. This approach allowed the engineering teams to continue their work uninterrupted while their data silently synced to the cloud.
Risk-free rehearsals
Once replication stabilized, we launched full copies of the environment in an isolated AWS sandbox. This testing phase enabled us to verify database integrity and application logic, correcting any configuration drifts before the first real user logged in.
Tuning for the cloud
Since cloud environments operate differently from physical hosts, we adjusted the system settings accordingly.
- Database alignment: We updated PostgreSQL settings, including pg_hba.conf, to accept connections within the new Virtual Private Cloud (VPC) structure.
- Storage mapping: We re-routed NFS paths to align with the new EC2-based storage layout.
- Modern connectivity: We replaced the reliance on static IPs with dynamic DNS resolution, enhancing the system’s flexibility.
The cutover
We executed the final transition swiftly during a pre-planned maintenance window.
- We stopped the legacy services to capture the final data state.
- We instantly spun up the production environment in AWS.
- Our engineers ran a final health check to confirm stability across all tiers.
- We updated public DNS records to point to the new AWS Load Balancer, bringing the modernized platform back online for users.
We transformed a fragile legacy setup into a stable, future-proof environment with minimal impact on end-users.
Near-zero downtime
The migration happened during a brief maintenance window. For most employees, the switch was invisible.
Eliminated existential risk
We avoided the “single point of failure”. The platform is now backed by the resilience of AWS availability zones.
Operational maturity
The client now has a transparent network, automated security logging, and the ability to scale resources with a few clicks.
Scalability with an upgrade roadmap
A flexible AWS architecture that enables RDS, EFS, and autoscaling, built in line with AWS Well-Architected principles.
“We were able to move a business‑critical platform off a fragile single‑host setup into AWS with almost no downtime. The new environment feels safer and more scalable, and we now have a clear path to further modernization without disrupting our teams.”
CEO, B2B fintech platform
