Cloud Migration & Architecture
We move existing systems onto AWS and design the setup they land in: accounts, networks, access and monitoring. Each workload gets a cost model before it moves, and a cutover plan that includes rollback.
Cloud migration and architecture means moving existing systems from your own servers or a data centre onto cloud infrastructure, and changing them where needed so they run well at a known cost. Our cloud work is on AWS.
The move is usually prompted by ageing servers, a hardware refresh or a compliance deadline. We assess each workload first, and sometimes the assessment says a system should stay where it is.
Is this the right fit?
You may need this if
Servers are reaching end of life
A hardware refresh forces a deadline for systems that cannot go offline for long.
The bill grew after moving
Workloads run at full size around the clock, and nobody knows which system drives the cost.
The AWS account has no design
Users, roles and security groups were added as needed, and nobody is sure what is exposed.
Data location is undecided
PDPA or a contract limits where data may be held, and the current design has not been checked.
What we deliver
Migration assessment
Per workload: what moves as it is, what changes first, what stays, and a cost model for each.
Landing zone and access
AWS accounts per environment, networking, least-privilege IAM roles, encryption and change logging, set up before workloads arrive.
Managed databases and storage
RDS, S3 and caching, with backup retention, maintenance windows and restore tests agreed with your team.
Cost visibility
Tags and budgets with alerts per team, then right-sizing and purchasing options once real usage is known.
Cutover and recovery
Parallel running or a planned window, a written rollback plan, and a recovery procedure rehearsed before go-live.
How we work
Every engagement runs through the same six-stage fitting process, from the first consultation to long-term care. The stages stay in the same order; how deep each one goes depends on the project.
See the full fitting process- ConsultationDiscover
- MeasureAnalyze and architect
- PatternDesign
- FittingBuild with you
- FinishingHarden and launch
- AftercareMaintain and support
What we settle before anything moves
In a data centre you pay for capacity up front, and an idle server adds little to the cost. In the cloud every running hour is billed, so a system moved without changes can cost more than before. Savings come from changing the workload: scaling down out of hours, using managed services and moving old data to cheaper storage.
Managed services take some operating work off your team, though not all of it. With RDS, AWS runs the hardware, takes automated backups and can apply minor patches in a window you choose. Your team still owns configuration, major version upgrades, access and restore tests.
Data location is the other early decision. PDPA, regulators and contracts can limit where data is held. Where it must stay in Thailand, we use a region in Thailand and check that each service the design needs is available there.
Organizations we work with
Engagements span build, integration and long-term support. Named with permission; clients under NDA are not listed.
Related services
- Application Modernization: when the application needs code changes before it can scale down.
- DevOps & CI/CD: when you also need a build and deployment pipeline.
- Data Migration: when the old system is being retired and its data moved.
- Solution Architecture: when you want the target design agreed before committing a budget.
Frequently asked questions
How much does a cloud migration cost?
It depends on how many workloads move, how much each must change, the data volume and how much downtime you can accept. We model the monthly AWS bill separately, per workload. We give a written estimate after a short scoping call, or price against the TOR for public-sector work.
How long does an AWS migration take?
A few weeks for one contained application. A larger group of systems moves in phases over several quarters, starting with the least risky workload to test the pattern and the cost model. The assessment gives you a sequenced plan with the continuity risk of each phase written down.
Will moving to the cloud reduce our costs?
Not by itself. A system moved without changes often costs as much as before, or more, because idle capacity is billed. We model the monthly cost per workload before you commit, including the changes needed to reach it, and for some systems the model says to stay.
How do we handle PDPA and data residency?
As architecture, decided early: which region holds each kind of data, what processing stays in Thailand, and what crosses a border under which controls. AWS has a region in Thailand, though not every service is offered in every region. Your legal advisers interpret your obligations; we build the technical measures.
Can you migrate without downtime?
Often, using parallel running and a staged cutover, though that costs more than a planned maintenance window. Weigh that against what an hour of downtime costs you. For many internal systems a planned window on a Sunday is cheaper and simpler. We plan and rehearse the rollback either way.
Next step
Start with a conversation
Tell us about the problem you are trying to solve. A senior person reads every inquiry and replies with our view of fit, scope and cost, including when another option would suit you better.