Cloud infrastructure that scales cleanly and costs what it should.
Cloud migrations fail in predictable ways: undocumented dependencies surface mid-migration, licensing issues only appear at scale, 'lift and shift' produces cloud infrastructure with the same architectural problems as the on-premise setup it replaced, and nobody has calculated the post-migration running cost against the on-premise alternative. We've run enough migrations to have seen all of these — and we design the architecture to avoid them. Our approach: document everything before touching anything, migrate workloads in priority order with rollback at each phase, and target a cloud architecture that's meaningfully better than what you had — not just the same thing running on someone else's hardware.
Cloud migrations fail predictably when undocumented dependencies surface mid-cutover, when 'lift and shift' reproduces the same architectural problems on someone else's hardware, or when nobody calculated the actual running cost before committing to the move. Origin Softwares runs cloud architecture and migration projects with dependency mapping before any migration step, Infrastructure as Code from the first commit, and a rollback plan at every phase. Organisations choose us after a previous failed migration attempt or when they cannot afford a production outage during the transition.
What is cloud architecture and migration?
Cloud architecture is the design of your infrastructure on cloud platforms such as AWS, Azure, or Google Cloud — covering compute, networking, storage, databases, security, and the connections between them. Cloud migration is the process of moving workloads from on-premise servers or from one cloud provider to another, while maintaining availability throughout the transition. Origin Softwares designs cloud architectures using Infrastructure as Code (Terraform or AWS CDK) so every resource is version-controlled and reproducible, and executes migrations in phases with rollback procedures at each step. A well-designed cloud architecture delivers better availability, lower operational overhead, and more predictable cost than the on-premise setup it replaces.
The problems this solves
- On-premise infrastructure is approaching end-of-life and hardware refresh cost rivals the cloud migration investment
- Current infrastructure cannot scale for traffic peaks without over-provisioning expensive physical hardware year-round
- Disaster recovery is manual and untested — actual RTO and RPO in a real outage are unknown
- Dev and staging environments differ significantly from production, causing deployment failures that only appear in production
- Security patching is months behind because updating on-premise infrastructure requires significant downtime coordination
- Engineering team spends significant time on infrastructure maintenance rather than product development
Business outcomes
- 40% average cloud running cost reduction compared to equivalent on-premise infrastructure at the same availability tier
- 99.99% availability on multi-AZ cloud architectures versus the typical 99.5% of on-premise setups without redundancy
- Infrastructure as Code means staging environments match production exactly, eliminating environment-specific deployment failures
- Disaster recovery becomes a Terraform apply rather than a manual reconstruction — RTO measured in minutes, not hours
- Auto-scaling handles traffic spikes without pre-provisioning — you pay for peak capacity only when you need it
- Security patching on managed cloud services happens automatically, reducing the patching backlog and associated risk
Who is this for?
Scale-up Engineering Teams
Teams whose on-premise infrastructure is constraining product growth and who need cloud architecture that scales with their user base without manual intervention.
Financial Services Firms
Regulated firms adopting cloud for cost and agility benefits who need architecture that satisfies data residency, encryption, and audit requirements.
Healthcare Organisations
Healthcare providers and health-tech companies needing HIPAA-compliant cloud architecture with proper PHI data handling and access controls.
Manufacturers Moving to Hybrid Cloud
Manufacturing operations migrating ERP and operational systems to cloud while maintaining on-premise connectivity for factory floor and IoT systems.
E-Commerce Businesses
Online retailers who experience significant traffic variability and need auto-scaling architecture that handles peak periods without over-provisioning year-round.
Teams After a Failed Migration
Organisations that attempted a cloud migration internally or with another provider and need the project completed reliably without further disruption.
When Cloud Architecture & Migration may not be the right fit
We'd rather tell you upfront than waste your time and budget.
- If your workloads have strict data localisation requirements that no cloud provider's regional offering can satisfy, on-premise or colocation may remain necessary
- If your applications have hard real-time requirements with microsecond latency that cloud network variability cannot reliably meet, edge or on-premise infrastructure may be more appropriate
- If your organisation has significant existing on-premise hardware under long-term contract with no budget for parallel running, a phased migration over the contract lifecycle may be the only viable path
- If your engineering team has no cloud operations capability and no budget for managed cloud services, the operational model change may be more disruptive than the infrastructure benefit
What's included
- AWS, Azure & GCP architecture design
- On-premise to cloud migration planning
- Infrastructure as Code (Terraform & CDK)
- Multi-region & high-availability design
- Containerisation & Kubernetes migration
- Networking, VPC design & security groups
How we deliver
Discovery & Dependency Mapping
Document the full current environment — every service, every dependency, every undocumented connection — before planning any migration step.
- Network traffic analysis to map all service-to-service communication
- Dependency mapping tooling deployed to surface undocumented connections
- Application-level tracing to identify hidden dependencies on shared services
- Licensing audit to identify software with cloud-incompatible terms
Architecture Design & Cost Modelling
Design the target cloud architecture, define availability and security requirements, and produce a cost estimate before any build starts.
- Target architecture designed per workload — lift-and-shift vs re-architect decision per service
- Multi-AZ availability design with RTO and RPO targets defined
- Security architecture: VPC design, IAM strategy, secrets management
- Cost estimate for cloud running cost reviewed and agreed before proceeding
Infrastructure as Code Build
Build the full cloud environment in Terraform or CDK, starting with non-production environments to validate the architecture.
- Terraform or CDK codebase built for full environment — every resource defined, nothing manual
- Staging environment deployed and validated against production configuration
- Network, security group, and IAM configuration reviewed against CIS benchmark
- Performance benchmarking in cloud environment against on-premise baseline
Phased Migration Execution
Migrate workloads in priority order with rollback at each phase — non-critical services first, stateful systems last.
- Non-critical workloads migrated first to validate the process and tooling
- Stateful services migrated with blue-green or database replication cutover approach
- Production cutover executed with rollback procedure ready and monitoring on
- Traffic shifted incrementally with health checks validating each step
Optimisation & Handover
Post-migration cost and performance review, knowledge transfer, and operational documentation.
- 30-day post-migration cost review with right-sizing and Reserved Instance recommendations
- Performance review against pre-migration benchmarks with tuning where needed
- Operational documentation and runbook finalisation
- Knowledge transfer session with engineering team on infrastructure operations
How long does a cloud migration take?
Timeline depends primarily on the number of workloads and how well the existing environment is documented. For a small organisation with fewer than twenty workloads and clear documentation, a complete migration takes two to four months. For mid-market companies with complex interdependencies and legacy systems, four to nine months is realistic. Enterprise migrations with hundreds of workloads, regulatory requirements, and significant legacy infrastructure typically run twelve months or more in phases. The most common cause of delays is undocumented dependencies discovered mid-migration rather than during the upfront audit. Origin Softwares spends the first two weeks on dependency mapping to reduce this risk before touching the source environment.
Technologies we use
- AWS
- Azure
- GCP
- Terraform
- AWS CDK
- Kubernetes
- Docker
- Helm
- AWS EKS
- Azure AKS
- CloudFormation
- Pulumi
Architecture & scalability
- Landing zone design: set up AWS Organizations or Azure Management Groups with security baseline accounts before migrating any workloads — retrofitting governance is harder than building it first
- Network topology: hub-and-spoke VPC design with a transit gateway for multi-account environments prevents direct VPC peering sprawl and simplifies security group management at scale
- IAM strategy: define service account permissions at the task level, not the team level — a Lambda that reads from S3 should have a role that only allows that specific action on that specific bucket
- Data transfer costs: cloud egress charges are frequently underestimated — model data transfer costs for your architecture before migration, particularly for high-throughput database replication and CDN origins
- Database migration approach: AWS DMS or Azure Database Migration Service for live replication with minimal cutover downtime; validate query performance in the cloud database before cutting over production traffic
- Compliance boundary design: if workloads handle regulated data (PHI, PII, payment data), define the compliance boundary explicitly in the VPC design and apply SCPs to prevent resources from being created outside it
Lift and Shift vs Re-architect vs Managed Services
| Criterion | Lift and Shift | Re-architect | Selective Re-architecture |
|---|---|---|---|
| Migration timeline | Fastest — weeks | Slowest — months | Medium — phased |
| Post-migration cost | Similar to on-premise | Lower — cloud-native patterns | Moderate reduction |
| Architecture improvement | None — same design on cloud | Significant — scalable by design | Improvement where it matters |
| Operational complexity | Same as before | Lower — managed services | Moderate — mixed model |
Why choose Origin Softwares
Our approach
- We map every dependency — documented and undocumented — before touching the source environment
- Every cloud resource is in Terraform or CDK from the first commit — no manual console resources, no undocumented infrastructure
- We define rollback procedures for every migration phase before executing any cutover
- We work across AWS, Azure, and GCP and recommend based on your workload, not on partnership incentives
- We have delivered zero-downtime phased migrations for organisations with complex legacy interdependencies
- Post-migration cost estimates are provided before commitment — billing surprises are a planning failure we design out
Delivery standards
- All infrastructure defined in Terraform or AWS CDK — version-controlled, peer-reviewed, and reproducible
- Multi-AZ deployment as baseline for production workloads — single-AZ is explicitly documented as a decision, not a default
- Network security designed with least-privilege security groups — no 0.0.0.0/0 rules in production
- RTO and RPO targets defined upfront and validated against the architecture before go-live
- Cost estimate for cloud running cost reviewed and agreed before migration execution
- Post-migration architecture review at 30 days with optimisation recommendations
Quality assurance
- Dependency map validated against network traffic analysis before migration planning is finalised
- Architecture design reviewed against cloud provider Well-Architected Framework before build
- Staging environment validated to match production configuration via Terraform plan comparison
- Performance benchmarking in cloud environment against on-premise baseline before production cutover
- Security group and IAM configuration reviewed against CIS benchmark before go-live
- Disaster recovery test run on the cloud environment before decommissioning on-premise infrastructure
Security practices
- IAM roles following least-privilege principle — service accounts with only the permissions required for their function
- No hardcoded credentials — all secrets in AWS Secrets Manager or HashiCorp Vault
- VPC design with private subnets for application and database tiers — public access only for load balancers
- CloudTrail enabled across all regions from day one — every API call logged
- Encryption at rest for all storage (EBS, RDS, S3) and in transit (TLS 1.2 minimum)
- Security groups reviewed against principle of least access — every inbound rule documented with justification
Performance
- Instance type selection based on production workload profiling — not conservative over-provisioning
- Database performance validated in cloud with representative query load before cutover
- CDN and caching configuration tuned for your traffic pattern before go-live
- Auto-scaling policies tested with load simulation to validate scale-out triggers
- Network latency benchmarked between services in the target architecture to validate inter-service communication
- Cost monitoring from day one with per-service attribution to identify unexpected spend early
What you receive
- Dependency map of current environment with all services and their interconnections
- Cloud architecture blueprint with cost estimate and availability design
- Terraform or CDK infrastructure codebase for the full target environment
- Phased migration plan with rollback procedures for each phase
- Network and security configuration documentation
- Go-live runbook and post-migration optimisation report
Support tiers
- Go-live support: 30-day post-migration support with daily monitoring reviews and rapid response to issues
- Managed cloud: Ongoing infrastructure management including cost optimisation, security patching, and scaling
- Infrastructure advisory: Monthly architecture review and guidance as your engineering team operates the cloud environment independently
- DR testing: Annual disaster recovery testing against your defined RTO and RPO targets
Why Origin for Cloud Architecture & Migration
Every resource in Terraform from the first commit
No click-ops, no undocumented resources, no 'I think someone created that manually'. Every cloud resource is in version-controlled Infrastructure as Code from day one.
Dependency mapping before the first migration step
We map every dependency — documented and undocumented — before touching the source environment. Surprises during cutover are a planning failure.
Rollback plan at every migration phase
Each phase of the migration has a defined rollback procedure. We don't cut over and hope. We cut over knowing exactly how to reverse it if something surfaces post-go-live.
Industries we serve
Typical delivery timeline
| Phase | Duration | What happens |
|---|---|---|
| Discovery & Mapping | 2 weeks | Full environment documentation, dependency mapping, and licensing audit. |
| Architecture Design | 2 weeks | Target architecture design, cost modelling, and security design review. |
| IaC Build & Staging | 3-4 weeks | Terraform or CDK build, staging environment deployment, and performance benchmarking. |
| Migration Execution | 4-8 weeks | Phased migration by workload group with rollback at each phase. |
| Optimisation & Handover | 2 weeks | Cost review, performance tuning, documentation, and knowledge transfer. |
Before you start — a checklist
Use this to prepare for your first conversation with us.
- Is your current infrastructure approaching end-of-life or capacity limits that would require significant capital expenditure to extend? Cloud migration converts capex to opex.
- Do you have documented RTO and RPO targets that your current infrastructure cannot meet? Cloud multi-AZ and managed database failover can close this gap.
- Are your dev and staging environments different from production? Infrastructure as Code makes them match exactly.
- Is your on-premise environment well-documented enough to migrate safely? Poorly documented environments need a discovery phase before migration planning.
- Do you have regulatory requirements (data residency, compliance frameworks) that constrain which cloud provider and regions are available to you?
- Does your team have the cloud operations capability to run the environment post-migration, or do you need managed cloud services to operate it?
Maintenance & support
- Monthly cost optimisation: right-sizing reviews, Reserved Instance strategy updates, and Savings Plans analysis as your usage pattern evolves
- Security posture reviews: quarterly review of IAM permissions, security group rules, and compliance configuration
- Architecture reviews: semi-annual review of the architecture as your product and traffic pattern evolve with recommendations for improvements
- Managed cloud operations: ongoing monitoring, incident response, patching, and scaling on a monthly retainer
- DR testing: annual disaster recovery exercise against your defined RTO and RPO targets with results documented for compliance
“We'd been told our migration would take three months. The previous agency got six months in and we were still on-premise. Origin spent the first two weeks doing a proper dependency audit, then migrated in phases over four months without a single production incident.”
Frequently asked questions
Planning & scope
- How do we decide which cloud provider to use?
- AWS is the default for most organisations — broadest service catalogue, most mature tooling, largest talent pool. Azure is the right choice when your organisation is already deeply invested in Microsoft (Active Directory, Office 365, Dynamics) and wants single-vendor management. GCP makes sense when BigQuery is at the centre of your data strategy. We work across all three and make the recommendation based on your workload and organisational context, not on commercial partnership incentives.
- Should we re-architect or just lift and shift?
- Per workload, not as a blanket policy. Workloads where the current architecture is sound and the main goal is hardware decommission: lift and shift. Workloads with known architectural problems — poor availability design, manual scaling, hardcoded configuration — are worth re-architecting for cloud-native patterns. We give you a recommendation per workload in the architecture design phase, with timeline and cost implications for each approach.
- How do we handle applications that cannot be migrated to cloud due to vendor licensing?
- We identify licensing constraints in the dependency mapping phase. Options include license renegotiation with the vendor, replacing the application with a cloud-native equivalent, retaining that workload on-premise in a hybrid architecture, or running the application on dedicated hardware instances in the cloud. We present the options with cost and complexity analysis before the migration plan is finalised.
- What is the risk of a production outage during migration?
- With proper dependency mapping and a phased migration approach using blue-green cutovers, production outage risk is low. We have completed migrations without production incidents by following the dependency mapping and rollback procedure methodology. The risk spikes when migrations are rushed or when dependency mapping is skipped — both are planning decisions, not inevitable outcomes.
Technical
- What is the difference between Terraform and AWS CDK?
- Terraform is cloud-agnostic Infrastructure as Code that works across AWS, Azure, and GCP with a consistent language (HCL). AWS CDK lets you define AWS infrastructure in programming languages (TypeScript, Python, Java) and compiles to CloudFormation. We prefer Terraform for multi-cloud environments and when the team wants a single IaC language. We prefer CDK when the team is deeply AWS-native and wants to use existing programming language skills for infrastructure. Both produce version-controlled, reproducible infrastructure — the choice is primarily based on your team's preferences and cloud footprint.
- How do you handle database migration with minimal downtime?
- Using continuous replication tools — AWS DMS, Azure Database Migration Service, or pglogical for PostgreSQL. We set up replication from on-premise to cloud database, validate data consistency, then execute a brief cutover window to flip the application connection string. The cutover window is typically 5 to 30 minutes depending on the database size and replication lag. We validate query performance in the cloud database under representative load before the cutover to avoid performance surprises at go-live.
- How do you design for auto-scaling?
- Auto-scaling requires defining scale-out triggers (CPU threshold, request queue depth, custom metrics), minimum and maximum instance counts, and a scale-in policy that doesn't remove capacity too aggressively during load spikes. We test scaling behaviour with load simulation before go-live. Common mistakes include setting minimum capacity too low (no buffer for sudden spikes) and aggressive scale-in policies that remove instances before the next request wave arrives.
- What networking design do you use for a multi-account AWS environment?
- Hub-and-spoke with AWS Transit Gateway. A central networking account hosts the Transit Gateway and shared services (DNS, VPN, Direct Connect). Spoke accounts connect to the hub and can communicate with each other through the hub. This design is more manageable than full mesh VPC peering, which becomes unworkable beyond 5 to 10 accounts. Security group rules reference security group IDs rather than CIDR blocks to maintain clarity as the environment scales.
Engagement & process
- Can you take over a cloud environment that was set up manually without Infrastructure as Code?
- Yes — we start by importing existing resources into Terraform so the current state is captured in code. We then audit for security and configuration issues, bring the environment up to our standards, and operate it from the IaC baseline. This process typically takes four to six weeks depending on the complexity of the environment.
- Do you provide managed cloud services after the migration?
- Yes — we offer managed cloud on a monthly retainer covering monitoring, incident response, cost optimisation, security patching, and scaling. This is the right model for engineering teams that want their cloud infrastructure operated professionally without building an internal cloud ops function.
- How do you handle knowledge transfer so our team can operate the cloud environment?
- Through documentation and hands-on pairing during the build and migration phases. We produce architecture documentation, operational runbooks, and troubleshooting guides. We pair with your engineering team on key operations tasks so the knowledge transfers practically, not just through documentation. The Terraform codebase is designed to be readable and maintainable by your team, not a black box.
What should you expect from a cloud architecture and migration provider?
A provider should give you a dependency map of your current environment before any migration begins — not discover dependencies at cutover. Every cloud resource should be delivered as Infrastructure as Code from the first commit: no manual console changes, no undocumented resources. Each migration phase should have an explicitly defined rollback procedure. The final architecture should meaningfully improve on what you had — not replicate the same design on cloud hardware. Origin Softwares provides post-migration architecture review at 30 days to identify any optimisation opportunities the live environment reveals. Expect a cost estimate for the cloud running cost before you commit to migration, not after the first billing cycle.
Related services
Custom Software Development
Applications migrated to cloud often need refactoring to take full advantage of cloud-native patterns and managed services.
Cloud & DevOps
Cloud architecture is the foundation — CI/CD pipelines and deployment automation make it operate efficiently.
Data Engineering
Cloud migrations that include data workloads need warehouse architecture and pipeline design to replace on-premise ETL systems.
Web Development
Web applications migrated to cloud benefit from CDN configuration, edge caching, and auto-scaling that cloud infrastructure enables.
Mobile App Development
Mobile backends migrated to cloud gain auto-scaling and global distribution that improves performance for users across geographies.
Not sure where to start?
Book a dependency mapping consultation and get a phased cloud migration plan with cost estimate within two weeks.
Get a free consultation