Kuala Lumpur · serving Malaysia & Thailand
Application Modernization Services
Aqvantiq modernizes legacy applications for organizations in Malaysia and Thailand: decomposing monoliths into services, containerizing with Docker and Kubernetes, and putting an API-first contract in front of the systems that stay. We are a multi-cloud system integrator in Kuala Lumpur, so the target can be AWS, Google Cloud, Huawei Cloud, Azure or DigitalOcean.
Application modernization, explained
Application modernization changes how an existing system is structured, packaged and deployed, so it can be changed safely and run economically on cloud infrastructure. It is worth doing when the cost of changing the application — not running it — becomes the constraint. Age alone is not a reason.
The runtime is out of support
An OS, framework or database past security patches. A deadline, and the first thing auditors find.
Releases have become events
One screen changes and you regression-test everything over a weekend window. Preparing costs more than deploying.
You scale the whole app to scale one part
One report drives the load, but the only lever is a bigger instance for everything.
Integration means database access
Other systems read your tables directly. Every schema change becomes a cross-team negotiation.
Knowledge sits with two people
Nobody else can safely change the code; onboarding takes a quarter. The fix is seams and tests.
Compliance needs evidence the app cannot give
No audit trail, shared credentials, no proof of who changed what. Retrofitting that is decomposition in disguise.
Choosing between rehost, replatform, refactor and rebuild
Pick the cheapest path that removes the symptom. Rehosting buys a deadline. Containerizing buys repeatable deployment. Decomposing buys independent scaling and release where needed. Rebuilding buys a clean slate at the highest cost and risk. Most estates use two of the four at once.
| Path | What changes | What it buys | What it costs | When we pick it |
|---|---|---|---|---|
| Rehost (lift and shift) | Nothing in the code. It moves as-is. | Fast exit from a data centre or end-of-life platform. | Lowest effort, lowest reward. Running costs often rise. | A hard deadline: lease expiry, hardware failure, a closing data centre. |
| Replatform | Packaging. The app becomes a Docker image; config and secrets move out. | Repeatable deploys, easy rollback, identical environments, autoscaling. | Weeks per application, plus a platform to run containers. | Code is sound, but delivery is slow and environments drift. |
| Refactor (decompose) | Structure. High-value capabilities become services behind APIs; the rest stays. | Independent deployment and scaling where needed. | Months, and real discipline — contracts, tests, data ownership. | One or two areas cause most of the pain or load. |
| Rebuild | Everything. A new implementation of the same capability. | A clean slate when the design cannot reach the requirement. | Highest cost, highest chance of re-creating the original problem. | Rules are documented and the code is beyond safe change. |
Sometimes the answer is do less: rehost a stable system and spend the budget on the application blocking your roadmap.
Splitting a monolith without stalling the roadmap
One capability at a time, behind the existing entry point. New requests route to the extracted service while everything else still hits the monolith, so the application never leaves production — and every step short of the data split reverses by flipping a route, which is exactly why the data moves last. Feature work carries on in parallel.
- 1
Find the seams
Read code and traffic together. Pick a capability with a clear boundary and its own data — not the easiest module.
- 2
Put the contract in first
Define the API first and make the monolith call it internally. A wrong interface surfaces while still one deployable.
- 3
Extract, dual-run, reconcile
Run the new service beside the old with mirrored or replayed traffic where it is safe to, and compare outputs. Discrepancies arrive as a report, not an incident.
- 4
Separate the data last
The service owns its tables in code long before it owns a database. Splitting a shared schema goes last.
What containerization and API-first change in practice
Containerization gives you one consistent deployable artefact across environments: one Docker image, configuration injected rather than baked in, rollback as a redeploy of the previous tag. Kubernetes adds scheduling, health checks and rolling updates. API-first — contract-first, strictly — means the interface is specified before the implementation, so consumers integrate against a contract, not your database.
Containerization
- Config and secrets out of files, logs to stdout, state off local disk.
- A real health endpoint, graceful shutdown, resource requests from measured usage.
- Image build and scan in CI, Terraform for the cluster, manifests in version control.
API-first
- A versioned OpenAPI specification per service, in the repository.
- An explicit deprecation policy — no surprise breaking changes.
- Contract tests in CI: a spec violation fails the pipeline.
- Authentication and rate limiting at the gateway, not per service.
- Idempotency and retry semantics defined for anything that writes.
- No direct database access from outside the owning service.
The honest cost
You now run a cluster — upgrades, node pools, certificates, capacity. For a handful of services a managed container runtime is often better, and we will say so.
Once capabilities have clean interfaces, adding an AI step becomes an integration — where AI adoption usually starts.
How modernization connects to CI/CD and day-2 operations
Directly — a modernized application is only an improvement if someone can deploy and operate it. Every engagement lands with pipelines in GitLab CI/CD, GitHub Actions or Jenkins, infrastructure in Terraform, and monitoring and restore in place before cutover. Easy to operate, not just easy to demo.
Build and ship
Build, test, scan and deploy on merge. Environments promoted by tag, credentials from workload identity.
DevOps as a ServiceRun and watch
Metrics, logs and traces per service. Alerts mapped to a runbook, restores actually tested.
Managed Cloud ServicesLand it somewhere sensible
Accounts, networking, identity and cost designed first, so new workloads inherit nothing broken.
Cloud ArchitectureDelivery is managed by Anson Lau, the founder — a former Silverlake Axis cloud DevOps engineer — and done by the same group of engineers, with the engineer who scoped the assessment staying accountable for what follows it.
Frequently asked questions
Can't find your answer?
Ask it directly and an engineer answers, usually the same working day.
Ask an engineer What is application modernization, and when is it worth doing?
Application modernization changes how an existing system is structured, packaged and deployed, so it can be changed safely and run economically on cloud infrastructure. It is worth doing when the cost of changing the application — not running it — becomes the constraint. Age alone is not a reason, and rehosting a stable system is often the honest answer.
Do we have to move to microservices?
No, and often you should not. Microservices trade a code problem for a distributed-systems problem — network failure, partial writes, versioned contracts, harder debugging. We carve out the two or three capabilities that carry the pain and leave the rest as a well-tested monolith. A modular monolith with a real CI/CD pipeline beats a badly split estate every time.
Can you modernize without a full rewrite?
That is the normal case. We containerize what runs, put a versioned API in front of what other systems need, then extract capabilities one at a time behind the existing entry point. The application stays in production throughout and every step is independently reversible.
Do we need a CI/CD pipeline before decomposing a monolith?
Yes, and if it does not exist it is the first thing we build. Contract tests hold the boundary between the monolith and each extracted service, automated builds keep those services shippable, and feature flags turn every cutover into a configuration change rather than a release event. See DevOps as a Service.
Which cloud does the modernized application run on?
Whichever your data, latency and procurement constraints point at. Aqvantiq works across AWS, Google Cloud, Huawei Cloud, Azure and DigitalOcean. Because the target is containers plus Terraform, the platform decision stays reversible — see cloud architecture consulting for how we make it.
What happens to the database?
It moves last. Splitting a shared schema is the highest-risk part of any decomposition, so we run new services against the existing database first, introduce ownership boundaries in code, and only separate the data once the service boundary has proven stable in production.
What actually improves after modernization?
Smaller deployable units with clearer ownership. The part under load scales on its own instead of the whole application, a decomposed service can be profiled and cached separately, and rollback becomes a redeploy of the previous image. We publish no percentage — we measure deployment frequency, lead time, time to restore and cost per environment first, so the result comes from your own data.
Do you work with organizations in Thailand?
Yes. Aqvantiq delivers across Kuala Lumpur and Bangkok. Modernization work for Thai enterprises runs alongside our cloud migration and DevOps practices — start at cloud consulting in Thailand.
Related services
Modernizing an application for a Thai business unit? Cloud consulting and system integration in Thailand covers cross-border engagements.
Tell us what the application is doing to you
Release pain, scaling cost, an unsupported runtime, an audit finding — send the symptom and we will name the path, including doing nothing.
Contact Aqvantiq