Portability Before the Bill
The Egress Fee Is Waived. The Engineering Cost Is Not.
In development, an architect, program office, or team lead often considers the requirements and makes infrastructure decisions only once, at the start of a project. These choices then quietly stay as permanent fixtures for the entire project’s duration. With rapid development and fast changes to technology, security standards, and compliance, more organizations and programs find themselves needing to migrate from one environment to another. A solutions implementation team needs to design with that possible change in mind. At the speed technology now changes, every IT leader should be reassessing whether those placement decisions are still structurally and financially sound, and doing it more than once.
Decisions That Are Only Made Once
Architecture for your company or organization is a huge decision and one that can have lasting effects on the project. Traditionally, once those choices are established, a project can find them very costly to revisit. A team starts a project, deploys it to a cloud environment, and then adds more to it until the cost begins to balloon outward. Most in this situation would consider the value they are getting back from their cloud provider and look at alternatives for hosting, but here is the trap: moving from one environment to another is extremely costly. In federal agencies, 17 out of 24 reported that controlling cloud costs requires changes to their IT management approach (U.S. Government Accountability Office [GAO], 2026). Eleven of those 24 agencies reported that adopting multiple cloud vendors introduced new technical problems, interoperability chief among them (GAO, 2026). Each additional vendor contract also carries its own fine print. GAO highlighted a case where a contractor migrated an agency’s data then required the agency to pay to regain ownership of their own data at the end of contract (GAO, 2024).
Figure 1. Cloud procurement challenges reported by 24 selected federal agencies. Seventeen agencies reported that cost control needs a change in IT management approach, and seventeen reported conflicting OMB and NIST software guidance. Fifteen reported outdated acquisition regulations, and fifteen reported difficulty obtaining authorized solutions. Eleven reported multi-vendor interoperability problems, and ten reported resource constraints on the cloud workforce.
This is not limited to government. In 2026, Flexera estimated wasted Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) spending at 29%, up after five years of decline, with 17% of organizations exceeding their public cloud budgets (Flexera, 2026).
What Has Changed in 2026?
Global supply chain issues around computer components and the rise of AI have been causing cloud costs to fluctuate. Flexera (2026) attributes the 2026 reversal in wasted cloud spending to that same cost complexity, driven by AI workloads and a widening set of IaaS and PaaS services. Cloud costs used to be steadier and better understood. A program would have to review their contracts and updated cloud policies to predict when leaving a provider would become worth the trouble. Providers may already charge no more than the costs they actually incur in moving a customer off their platform, and beginning January 12, 2027, in-scope providers are prohibited from imposing any switching charges at all, which puts a hard date in front of programs weighing a move this next fiscal year (Regulation (EU) 2023/2854, 2023).
Figure 2. EU Data Act milestones and hyperscaler egress waivers from 2024 to 2027, shown schematically and not to scale. The Data Act entered into force on January 11, 2024, and applies from September 12, 2025, with switching charges prohibited from January 12, 2027. Google Cloud waived egress fees on January 11, 2024, AWS on March 5, 2024, and Microsoft on March 13, 2024.
The regulation binds providers offering services in the EU rather than US agencies directly. The hyperscalers applied their waivers globally in advance regardless. Microsoft documents its own version as a support request a departing customer has to file (2026). The broader claim sits with the company rather than its documentation: Microsoft told Network World the exemption aligns with the Data Act and is available to Azure customers in any region (Thomas, 2024).
All three hyperscalers moved early to stay in front of each other. Google waived egress fees for departing customers on January 11, 2024 (Google Cloud, 2024); AWS matched it on March 5, 2024 (Amazon Web Services [AWS], 2024) and Microsoft on March 13, 2024 (Thomas, 2024). All three run the waiver as a conditional credit rather than a price change: the customer requests it through the provider’s support channel and completes the transfer inside 60 days, and in Google’s and Microsoft’s cases terminates the agreement or cancels every associated subscription before the credit is applied. That makes the waiver a process a program office has to plan for, not a discount it can assume.
Even then, the credit is not guaranteed. The UK Competition and Markets Authority reviewed all three waiver programs and found that eligibility sits largely with the providers, decided by a support team rather than an automated check (Competition and Markets Authority [CMA], 2025). There is more fine print to examine beyond that. Microsoft limits the credit to data transferred out via the internet (Microsoft, 2026). Follow that limit through and a program moving bulk data across a dedicated connection such as ExpressRoute is still paying the usual rate. AWS warns that a repeat applicant draws additional scrutiny (AWS, 2024). With the fee for moving data out now waived, a program office or contracting officer can put the switching cost on paper as a number. They can also negotiate that number with the contractor doing the work, who may end up carrying part of the migration risk, both technical and financial.
This is why portability is no longer a philosophical debate for solutions implementers and is now a lever program offices can and likely will pull this coming fiscal year.
Three Things ACC3 Learned by Being Deployment Agile
Moving from exclusively DoD contracting to commercial work has taught our team some valuable lessons. A client who asked us to build their cabin rental platform pushed us toward maintaining infrastructure and support ourselves. The team built with that intention in mind, but as the site was about to go live, we pivoted to a partner’s hosting platform. We managed to pull off the pivot in less than two weeks—from a cloud container to an orchestrated server architecture. This was one of multiple moves that taught us valuable lessons about environment management and transitioning between one environment and another.
Lesson 1: The Bill Is Not the Cost
As stated, the price of moving data from one cloud to another is not where the real cost of migration sits. The surprises arrive when a team never treated migration as an option in the first place. Over time, teams can build cloud-specific components and capabilities, and an engineer later has to map every one of them and re-engineer it for the next environment. When this happens, the cost is in engineering and refactoring a project to work in a different cloud or server environment, along with the technical hurdles nobody saw coming. If a project is old enough, finding the correct resources to assist with migration could add to the cost in ways that are hard to quantify before a decision is made.
This is not even considering a project built on a contracted platform vendor who, in ACC3’s experience, might not support migrating off their PaaS offerings to another type of environment. The GAO noticed that vendors can charge extra to run their own software on a competitor’s infrastructure or require repurchase of licenses already owned (GAO, 2024).
Lesson 2: The Compliance Boundary Moves Regardless
The Federal Risk and Authorization Management Program (FedRAMP) CR26 replaces “FedRAMP Authorization” with “FedRAMP Certification.” The rules took effect on July 4, 2026, and apply immediately to any cloud service offering obtaining or maintaining a certification, with enforcement beginning after January 1, 2027 (FedRAMP, 2026). The currency of compliance changes rapidly. All solution implementation teams need to actively work through this problem. When a team migrates workloads to a new environment, the security rules change with them. Authorization boundaries and shared responsibility are not portable by default. Old security paperwork becomes unreliable in this new setting. Therefore, moving workloads does not change the need for new paperwork that provides authorization or certification (Cybersecurity and Infrastructure Security Agency, 2022, Section 3).
Lesson 3: Providers Are Not Interchangeable
Vendor lock-in is nothing new, but cloud-agnostic does not have to mean lowest common denominator. It means an engineer can map the technical configurations of one system onto another and can say plainly which ones have no counterpart. Reaching for a provider-specific capability is the right call when a program knows its dependencies at the architecture level and has a documented exit strategy. ACC3 frames the goal like this: manage vendor concentration risk rather than chase the absence of lock-in.
We design to that framing, and it is what separates ACC3 from vendors who sell multi-cloud as an ideology. Teams fixated on avoiding lock-in usually miss where the problem starts. DoD officials pointed out in GAO (2023) that egress fees were not the primary cause of lock-in; they pointed instead to staff skill gaps and reliance on provider-unique services.
ACC3’s engineers have worked across a long list of platforms and environments. They know what it takes to deploy a containerized application inside a security boundary and walk it through the cybersecurity approval process, and they have moved workloads from one environment to another when a client called for it.
Designing for an Exit
The exit path is a design requirement, written down before the first sprint. A program that waits until a contract goes sideways ends up writing a recovery plan under pressure, and by that point in time, almost every meaningful choice has already been made for it.
Start with the dependency inventory. An engineer lists every provider-specific service the system touches along with its version, then puts a name against each one as owner and keeps that list current from the first sprint rather than rebuilding it in the middle of a migration scramble. Configuration has to be described in a form somebody can rebuild elsewhere. If it lives only inside a provider’s console, it does not exist for exit purposes. The compliance boundary is its own artifact, kept separate from the application logic it protects, so that when the system moves the boundary definition moves with it as a document a reviewer can actually read.
None of this is new. The National Institute of Standards and Technology (2012) identified portability as a known limitation of PaaS and SaaS in SP 800-146. Fourteen years on, it is still unsolved in practice, mostly because teams get to it after the architecture is already fixed.
When a program office asks what it would cost to leave a provider, the answer is already written down. We keep traceable requirements and specs current for every project, which lets us map the friction points quickly and hand the client a transparent cost analysis.
Experiences We Can Share
The public proof is Tenkiller Hideouts, a production product built on these principles, running now and open to inspection by anyone who wants to look at it.
The harder proof happened behind closed doors on short notice. We relocated a full, complex product from one cloud provider to another with only two weeks’ notice. On a separate engagement, our engineers moved a different system off the public cloud and onto on-premise bare metal, again, all in under two weeks. Both were live migrations under real operational pressure, not tabletop exercises.
We cannot detail those government programs in an open document. That is the baseline reality of the national security and defense sector, and we make no apology for it. Authorized program offices and interested parties who have clearance can reach out to ACC3 International to discuss under NDA.
Conclusion
Pick one workload or one placement decision you have coming up in the next quarter and give us time with your subject matter experts, not your engineers. We will show you what we can do in a short amount of time. It is a working session, not a demo, and the only ask is that you bring your ideas. In return, we will give you a strong solution and plan of action in days, not weeks.
References
Amazon Web Services. (2024, March 5). Free data transfer out to internet when moving out of AWS. AWS News Blog. https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/
Competition and Markets Authority. (2025). Cloud services market investigation — Appendix N: Egress fees and free switching programmes. https://assets.publishing.service.gov.uk/media/688b8169fc784fa12a089071/Appendix_N_-_Egress_fees___free_switching_programmes.pdf
Cybersecurity and Infrastructure Security Agency. (2022). Cloud security technical reference architecture (Version 2). https://www.cisa.gov/resources-tools/resources/cloud-security-technical-reference-architecture-tra
Federal Risk and Authorization Management Program. (2026). What’s changing in 2026. Consolidated Rules for 2026. https://www.fedramp.gov/2026/providers/updating/changes/
Flexera. (2026). State of the cloud report. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
Google Cloud. (2024, January 11). Eliminating data transfer fees when migrating off Google Cloud. Google Cloud Blog. https://cloud.google.com/blog/products/networking/eliminating-data-transfer-fees-when-migrating-off-google-cloud
Microsoft. (2026). Bandwidth pricing. Microsoft Azure. https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/data-transfer-fees
National Institute of Standards and Technology. (2012). Cloud computing synopsis and recommendations (NIST Special Publication 800-146). https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-146.pdf
Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act). (2023). Official Journal of the European Union, L 2023/2854. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng
Thomas, P. A. (2024, March 14). Microsoft Azure removes exit fee as EU regulations kick in. Network World. https://www.networkworld.com/article/1313681/microsoft-azure-removes-exit-fee-as-eu-regulations-kick-in.html
U.S. Government Accountability Office. (2023). Cloud computing: DOD needs to improve tracking of data user fees (GAO-23-106247). https://www.gao.gov/assets/gao-23-106247.pdf
U.S. Government Accountability Office. (2024). Cloud computing: Selected agencies need to implement updated guidance for managing restrictive licenses (GAO-25-107114). https://files.gao.gov/reports/GAO-25-107114/index.html
U.S. Government Accountability Office. (2026). Cloud computing: Federal government needs to address procurement challenges (GAO-26-107530). https://www.gao.gov/products/gao-26-107530
