# A cloud migration that plans for downtime and cost surprises up front. > Cloud migration to AWS, Azure, GCP or in-country data centers: inventory, migration strategy per system, cost model, wave plan and tested rollback. Source: https://www.algofact.tech/en/services/cloud/cloud-migration Language: en-US Updated: 2026-10-26 Languages: en-US, tr-TR ALGOFACT moves applications running on on-premises servers or another provider to AWS, Azure, GCP or, when data residency requires it, to data centers inside the required country, including Türkiye. Before anything moves, we map the application inventory and dependencies, choose a migration strategy and monthly cost model for each system, and run every wave with acceptance tests and a rollback plan. The work is delivered from our engineering offices in Adana and Ankara TEKMER under an ISO 27001:2022 certified information security management system. ## Key facts - **Target platforms:** AWS, Azure, GCP or in-country hosting - **Data residency:** Placement mapped to GDPR, KVKK and sector rules - **Planning:** Migration in waves, rollback for each wave - **Cost:** Monthly running cost modeled before the move - **Information security:** ISO 27001:2022 certified - **First step:** Discovery call and inventory review ## When does a cloud migration make sense? A migration is worth serious consideration when a hardware refresh is coming up, when capacity runs out at peak times, when backup and disaster recovery depend on one person’s knowledge, or when new AI and data projects need compute you can scale up and down. Not every workload belongs in the cloud. A steady, heavily used workload can stay cheaper on your own hardware, license terms can tie software to a specific environment, and some data has to stay in a given country by law. At the end of the assessment our recommendation for some systems may be to leave them where they are, and for others to retire them altogether. We state that plainly in the report, with the reasoning. ## What we migrate Most migration scopes are a mix of these workloads. ### Business applications ERP, CRM, accounting and in-house web applications, together with their integrations and scheduled jobs. ### Databases PostgreSQL, SQL Server, MySQL or Oracle databases moved to managed services or cloud virtual machines, with data validation and synchronization included. ### File shares and document archives Network shares and document archives moved to object storage or managed file services with their access permissions preserved. ### Data and AI workloads Scalable compute and storage for data warehouses, reporting and model training, with GPU capacity when needed. ### Provider switch and repatriation Moving from one cloud provider to another, or from public cloud back to a private or in-country data center. ## How a migration runs ### Inventory and dependency map We map servers, applications, databases and the connections between them. Hidden dependencies such as hard-coded IP addresses, shared file paths and overnight jobs are where migrations most often stall. ### Strategy per system Each system gets a decision: rehost, replatform, refactor, retain or retire. The decision is written down with its reasoning on cost, risk and your team’s capacity. ### Target architecture and landing zone Account structure, networking, identity, central logging and backups are in place before the first system moves, and every later wave reuses that foundation. ### Pilot wave We start with a low-risk system and rehearse the migration steps, data validation and rollback procedure under real conditions. ### Migration in waves The remaining systems move in waves planned around your business calendar. Each wave has a downtime window, acceptance tests and a clear criterion for a rollback decision. ### Optimization and closeout In the weeks after cutover, resources are resized to real usage, old servers are shut down and the operations handover is completed. ## What you receive ### Migration assessment report Inventory, dependency map and the recommended strategy for each system with its rationale. ### Cost model Expected monthly running cost on the target platform, a comparison with today’s cost and reservation or savings plan options. ### Landing zone code Accounts, networking, identity, logging and backup definitions, as code in your repository. ### Wave plan and rollback procedures Schedule, acceptance criteria and the steps back to the old environment for each wave. ### Operations guide for the new platform Step-by-step instructions for restores, scaling and routine maintenance. ## Data residency, cost and rollback The technical success of a migration depends on getting these four decisions right at the start. - **Data residency:** GDPR, KVKK in Türkiye and sector regulators can restrict where personal or regulated data may be stored and how it may be transferred. We place each workload in a provider region or in-country data center that meets the requirement and document which data lives where. - **Cost control:** A cloud bill does not shrink on its own. A tagging standard, budget alerts, cleanup of idle resources and a reservation plan for always-on workloads are set up as part of the migration. - **Rollback plan:** The old environment stays up until the new one passes acceptance tests and an agreed observation period ends. If data is not synchronized both ways, the rollback path is rehearsed before cutover. - **Downtime management:** The downtime window is agreed with business owners. For systems that cannot tolerate a long outage, database replication reduces cutover to a short switch. ## Questions about cloud migration ### Which cloud provider do you recommend? We are not tied to any provider. The choice depends on your data residency requirements, the licenses you hold, your team’s experience and the cost model. AWS, Azure and GCP are all on the table, as are in-country data centers where residency rules apply. ### Will our systems go down during the migration? Each wave has a planned downtime window agreed with your business owners in advance. For systems that cannot accept an outage, data is synchronized ahead of time and the move becomes a short switchover. ### What if the bill comes in higher than expected? The cost model is built before the move and budget alerts are live from day one. During the optimization period resources are scaled down to real usage, and any gap against the model is reported with its cause. ### Can you migrate workloads that must stay in Türkiye? Yes. When KVKK or a public-sector requirement keeps data in the country, we plan the move to data centers hosted in Türkiye. ALGOFACT also holds the Kamu Bilişim Yetki Belgesi, which authorizes public-sector digital work in Türkiye. ### Who runs the new platform after the migration? Your team, or us if you prefer. Access and the operations guide are handed over; if you want continued operations support, we carry on under a managed support agreement. ### What drives the timeline and cost of a migration? The number of systems and databases, data volume, how well dependencies are documented, the acceptable downtime, how many applications need refactoring and compliance requirements. After the assessment we present the wave plan, expected duration and monthly running cost on the target platform in writing. ## Related - [Cloud](https://www.algofact.tech/en/services/cloud) - [DevOps and CI/CD](https://www.algofact.tech/en/services/cloud/devops) - [Managed IT and application support](https://www.algofact.tech/en/services/cloud/managed-it-support) - [Discovery call](https://www.algofact.tech/en/contact)