Every few months a story circulates about a company that has left the public cloud and saved a fortune. It is usually followed by a counter-story about a company that tried, failed and went back. Both are told as verdicts on the cloud itself, and both are mostly useless to anyone making a real decision, because the conditions that made them true are rarely in the headline.
A placement decision is an assumption about a workload: its demand, its cost, the services it needs, the rules it must follow and the team that runs it. Assumptions change. Demand that was unpredictable becomes steady. A managed service that fitted stops fitting. A regulation shifts, or an acquisition brings a better platform with it. When the assumption changes, the placement may need to change too, in either direction, and that is not an admission of failure. It is the same discipline that justified the original move.
This final part covers three ways of correcting placement: keeping a workload where it is, bringing one back, and switching one off. Bushbuck Brands is fictional, and its systems and figures are illustrative. By this point in the series Bushbuck, the South African distributor whose first rehosted wave ran well over budget, has controls, owners and a working platform. It now has to decide what to do with the workloads that still do not fit.
Retain is a decision, not a delay
The migration frameworks all include some form of retain: keep the workload where it is for now. AWS lists reasons such as data residency, specialised hardware and applications with no business value to migrate. Microsoft's Cloud Adoption Framework describes retaining workloads that are stable and compliant where migration offers low return. Neither treats it as a failure to migrate.
What makes retain a decision rather than a delay is the same discipline as every other treatment in Part 3: a recorded reason, an owner and a date when the decision will be reviewed. Bushbuck retained its finance ERP on premises, because an ERP upgrade is planned for 2028 and moving the current version now would mean migrating it twice. The decision record names the financial director as owner and the upgrade project as the trigger for revisiting it. It also notes the cost of retaining: the ERP is now the main reason Bushbuck still needs a small on-premises footprint after the co-location contract ends in June 2027, which is a cost the business has accepted knowingly.
The broader question of when on-premises and private infrastructure remain the right answer is covered in the previous series, in when on-premises and private cloud remain valid. This part is narrower: what to do when a workload is already in the cloud and may not belong there.
Repatriation needs the same discipline as migration
Repatriation, moving a workload from public cloud back to on-premises or co-located infrastructure, does not appear as a named strategy in the major providers' migration guidance. That is not surprising, and it does not make it wrong. It means the method has to come from the organisation, and it should be no less rigorous than the one used to move the workload in the first place.
Six steps keep the decision honest:
- Identify the measurable problem. "The cloud is expensive" is not a problem statement. "Storage and transfer cost for this workload has grown 40% in two quarters while its use has not changed" is.
- Test whether it can be solved in place. Most cloud cost problems are sizing, scheduling, storage tiering or design problems, and they can be fixed where the workload already runs, faster and more cheaply than moving it.
- Compare equivalent service levels and full operating cost. The on-premises comparison must include the hardware refresh, power, cooling, space, backup, monitoring, patching, security and the people who do all of that, at the same availability and recovery level the workload has today.
- Price the move itself. Migration effort, downtime, data transfer out of the cloud, parallel running and any skills the team does not currently have.
- Define the target operating model. Who will run it, patch it, back it up and answer the call at 2am, and do they have the time?
- Preserve a future change path. Keep the workload portable enough that the decision can be reversed if conditions change again: infrastructure defined in code, data in open formats, no new hard dependencies.
Bushbuck applied the test to two workloads.
The warehouse management system failed at step two. Its cloud bill was well above plan, and some in the business argued it should go back on premises with the ERP. But the problem was the one Part 1 had already found: it had been rehosted on machines sized for the old hardware's peak. Once it was rightsized on three months of measured demand and its database moved to a committed baseline, its cost fell below the business case. Moving it back would have bought new hardware to fix a configuration problem.
The distribution centres' camera footage passed every step. CCTV recordings from the three distribution centres had been sent to cloud object storage as part of a security upgrade. The footage is written continuously, kept for 90 days under Bushbuck's policy, and viewed almost exclusively by the security team at the site where it was recorded, usually within a week. Storage grew steadily with retention, the site links carried a constant upload, and lower storage tiers did not help much because recent footage was the part people actually watched. On-site storage at each centre met the same retention and access needs at a lower full cost, the one-off move was small, and the centre teams already ran local equipment. As a change path, footage linked to an incident is still copied to cloud storage for evidence and investigation.
Notice what the camera footage did not prove: that the cloud was the wrong choice for Bushbuck, or for storage in general. Proof-of-delivery images, which are smaller, read from anywhere and needed by finance and customer service as well as the depots, stayed in cloud object storage with lifecycle tiers. The test was applied to a workload, not to a platform.
Retirement often beats relocation
The most valuable migration decision is frequently the one that moves nothing. Every application that is relocated carries its costs to a new address: its licences, its integrations, its attack surface, its support work and its copies of data. An application that is retired takes all of those with it.
Across its programme, Bushbuck retired 19 applications: duplicate reporting tools built by different departments over the years, shadow databases that copied production data for one-off analysis, and the legacy leave application whose job the payroll product already did. None of them was migrated. Together they removed licence renewals, a dozen integrations nobody wanted to retest, several servers that had not been patched in years, and copies of personal information that served no current purpose and were a POPIA exposure in their own right.
Retirement is harder than it looks for one reason: nobody is sure who still uses the thing. Three practices help:
- Measure use before you ask. Access logs and database connections show who actually uses an application, which is often a smaller group than the one that will say they need it.
- Switch off before you delete. Disable access for a defined period with a clear route to request it back. Silence is evidence.
- Archive the data deliberately. Keep what retention policy or law requires, in a form that can be searched without the application, and delete the rest.
Correcting placement without ideology
The thread through all three decisions is that placement should follow evidence about a workload, not a belief about a platform. "Cloud first" and "cloud exit" are both slogans, and both lead organisations to make the same mistake: applying one answer to workloads that need different ones. The six-step test, the treatment worksheet from Part 3 and the unit-cost review from Part 5 are the same discipline applied at different moments.
By the end of the programme, Bushbuck's monthly cloud bill had come down to roughly R1.35 million from its peak of about R1.9 million, while order volumes grew and cost per order line shipped fell month on month. These are Bushbuck's own illustrative figures, and the saving came mostly from the unglamorous work: rightsizing, scheduling, removing duplicated backups and logs, retiring applications and moving one workload back on site. No single decision produced it, and no general percentage can be drawn from it.
Common mistakes
- Treating repatriation as a verdict on the cloud. It is a decision about one workload under specific conditions.
- Repatriating a sizing problem. If the cost can be fixed in place, moving it buys hardware to fix configuration.
- Comparing the cloud bill with the hardware price. The on-premises side must include people, power, space, refresh and recovery at the same service level.
- Retaining without a review date. A retained workload with no trigger is a decision nobody will ever revisit.
- Migrating applications nobody uses. Every relocated application keeps its licences, integrations, attack surface and data copies.
- Deleting before switching off. Disable first, wait, and let silence confirm the retirement.
A decision you can defend
We will move the distribution centres' camera footage from cloud object storage to on-site storage at each centre, because it is written continuously, viewed locally and its full cloud cost has grown with retention while on-site storage meets the same 90-day policy at lower full cost. Footage linked to an incident will still be copied to cloud storage for investigation. We will keep the warehouse management system in the cloud, rightsized, because its cost problem was solved in place. We accept that the centre teams now operate more local equipment. We will review the footage decision if retention rules change, if footage needs to be viewed from more than one site, or after two years of operation.
Series conclusion
Cloud is a way of operating technology under variable demand and continuous change. It rewards organisations that let demand, not forecasts, decide capacity; that treat migration treatments as decisions with owners and dates; that choose runtimes from the shape of the workload; that design cost in before deployment; and that move their operating model along with their servers.
The organisation receives value when architecture, finance, security and product ownership respond to that model together. When they do not, the cloud becomes what this series' title warns against: another data centre, with a meter attached.
What to take from this part
Placement is an assumption, and assumptions change. Correcting it in either direction is discipline, not failure.
Test repatriation like a migration. Six steps, starting with a measurable problem and whether it can be fixed in place.
Retain on purpose. Record the reason, the owner and the trigger for review.
Retire before you relocate. Switching an application off removes every cost it carries.
That completes the series. Start again from Part 1, or see every part on the series page.
How CloudNala can help
We help organisations correct placement decisions on evidence: applying the repatriation test to workloads that do not fit, building full like-for-like cost comparisons, finding applications that can be retired and planning their switch-off, and recording retain decisions with owners and review triggers. We have no stake in where a workload runs, only in whether the decision can be defended.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za