Cloud Migration
Cloud Migration
What is cloud migration?
- Assign each system its own migration approach (the 6 Rs)
- Rehosting is fast but offers few benefits
- Post-migration cost management decides success
What really changes after migration is not where the servers sit but the approval chain. Before, you submitted one purchase request for equipment, got it approved, and used it for three to five years. Now a bill arrives every month, so the people spending the money shift down to the product development teams. Spending that the procurement team used to control annually is now scattered day by day, so you need to redraw who can turn on resources and who is accountable for the cost on the org chart.
When you actually list out systems under the six approaches, most end up as rehost or retain. Discontinued vendor packages, in-house systems with no surviving source code, and integration servers tied to specific equipment each account for about a third of the total. It is safer to assign refactor only to systems with highly variable traffic that will keep gaining features for 3+ years. Note that cloud migration and cloud-native transformation are two different projects. The former moves infrastructure; the latter changes application architecture and deployment methods, so each needs its own budget and timeline.
The biggest cost leak is in the middle of the migration. During the parallel-run period, when on-premises equipment can’t yet be shut off while cloud resources are already running, costs flow out on both sides, and dedicated-line upgrades and data egress fees pile on. Cap the parallel period at under three months per system, and get executive agreement up front that old equipment is powered down once the deadline passes. A migration plan with no shut-off date is not a cost plan.
A common myth is that moving to the cloud reduces the need for administrators. Fewer people handle hardware, but you now need people to design permissions, networking, and billing. When that role is empty, development teams spin up resources however they like, and security groups can sit open for months. Incidents where the monthly bill jumps to two or three times the estimate usually come not from insufficient performance but from test instances that were never shut down. The expectation that moving makes things faster also often falls short. Systems that connected in milliseconds on the internal network can actually slow down once traffic crosses the internet, so tightly integrated systems should be moved together.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”Public cloud services spread in the late 2000s, and companies began debating migration strategies. Gartner outlined five migration types, which Amazon Web Services later expanded into six (the 6 Rs), and the framework has since become widely used.
Company A makes auto parts, with 520 employees and annual revenue of KRW 180 billion (≈ US$134,670,100). Its external data center lease ends in eight months, and replacing 20-plus aging servers would cost about KRW 600 million (≈ US$448,900). The information strategy team was stuck between 'let’s move everything now' and 'touch it and the production line stops.' (Hypothetical example)
- When the head of information strategy laid out 62 servers and 38 business systems on a single sheet, 9 systems had no access records at all in the past six months. Once the relevant department heads confirmed, those systems went straight onto the retirement list.
- In the migration-approach meeting, the production management director put his foot down: “Anything wired to the equipment controllers can’t be moved.” So they decided to keep the 11 servers inside the plant on-site and switch the groupware and HR systems to commercial SaaS.
- Legal review required payroll and HR data to stay in domestic regions only, and the sales system shared with overseas subsidiaries needed access permissions split by region, which added 6 weeks to the schedule.
- After moving the low-priority internal wiki and document servers first, the bill budgeted at KRW 1.8 million (≈ US$1,350) a month came to KRW 3.1 million (≈ US$2,320) in the first month. The specs had been set too high, so the team cut them in half and added automatic overnight shutdown.
- Fourteen months later, 26 of the 38 systems had been moved and 9 retired. Infrastructure costs, which had been KRW 240 million (≈ US$179,600) a year including rent and equipment replacement, fell to KRW 170 (≈ US$1) million, and the time to prepare a new development server dropped from three weeks to one day.