Migration deep dive

Akamai to Cloudflare: 101 domains, zero downtime.

A global brokerage and trading platform · Financial services · Global

How Nanosek migrated 101 production domains from Akamai to Cloudflare for a global brokerage and trading platform, preserving availability while rebuilding CDN, WAF, bot management, DNS and Layer 3 protection.

101

production domains migrated

reported migration downtime

months, discovery to cutover

minute support SLA after go-live

Plan a migration like this Our Akamai migration service

On this page

Overview Why the move Challenges Execution Architecture Results Lessons Technology

The engagement

A global brokerage and trading platform needed to move a large, security-sensitive production estate away from Akamai without creating a maintenance window or weakening protection during the transition.

The environment covered 101 production domains and supported public-facing financial services that were regularly exposed to automated abuse, attack traffic and attempted exploitation. The migration also had a hard commercial deadline: the new platform needed to be fully operational before the existing Akamai agreement expired.

Nanosek designed and executed a phased migration to Cloudflare that rebuilt the customer’s CDN and application-security controls, introduced additional Layer 3 protection with Cloudflare Magic Transit, and kept Akamai available as a fallback until the new path had been validated.

Result: All 101 domains were migrated to Cloudflare without reported migration downtime, while the customer retained a controlled rollback path throughout the transition.

The estate, domain by domain

One dot per production domain. Batches are illustrative — the totals are not.

On Akamai 101Validating via CNAME 0Live on Cloudflare 0

Zero reported downtime maintained throughout

The 101 domains inventoried; Akamai behavior documented and mapped to Cloudflare controls. Everything still serves from Akamai.

Why the customer moved away from Akamai

The customer had used Akamai for years, but its requirements had evolved beyond a straightforward CDN deployment. The production estate was under frequent attack and the security team wanted tighter control over application-layer protection, bot traffic, rate limiting and DDoS mitigation.

Performance mattered as well, but the primary requirement was operational confidence: the replacement platform had to withstand hostile traffic, preserve legitimate user flows and allow the security and infrastructure teams to change controls quickly without introducing unnecessary complexity.

Cloudflare was selected as the target platform because it could consolidate CDN delivery, application security, bot controls and DDoS protection while also extending protection beyond HTTP through Cloudflare Magic Transit.

“The difficult part was not choosing the target platform. It was moving 101 live domains with different behaviors and dependencies without changing how the applications behaved in production.”

The migration challenges

Four problems shaped the engagement — and each one influenced the architecture rather than being handled as an afterthought.

Migrating 101 active domains on a fixed deadline

The project had to be completed within approximately two months and before the customer’s Akamai contract expired.

A conventional “big bang” cutover would have introduced unnecessary risk. The estate included production systems receiving real customer traffic and regular attack traffic, so every stage of the migration needed to preserve both availability and security coverage. The migration plan therefore had to support:

Staged onboarding rather than a single cutover event
Parallel operation with Akamai during validation
Per-domain testing before traffic moved permanently
A practical rollback path if unexpected application behavior appeared
Security validation under real production conditions
Completion before the commercial deadline without paying for an extended overlap between providers

Translating Akamai behavior instead of copying configuration

Akamai and Cloudflare do not model every CDN and security behavior in the same way. Treating the project as a direct configuration copy would have created gaps and unnecessary technical debt.

Nanosek first documented the behavior of the existing Akamai estate and then mapped each requirement to the most appropriate Cloudflare control. Where Cloudflare offered a cleaner native implementation, the configuration was redesigned rather than reproduced literally.

Migration scope

Application & origin behaviorCDN & cache configurationDNS records & proxyingRedirects & URL handlingPage-rule equivalentsWAF policiesCustom security rulesBot-management controlsRate-limiting logicRequest/response transformsCertificates & TLSLogging & troubleshooting

Preserving a safe fallback while validating Cloudflare

The customer could not accept a migration plan where the first meaningful test happened after DNS cutover.

Nanosek onboarded a staging path first and used a CNAME-based migration approach to place Cloudflare in front of selected traffic while Akamai remained available behind the migration design as a fallback. This allowed the team to observe application behavior, caching, headers, security actions and origin communication before committing each zone to its final architecture.

After validation, zones were transitioned to a full Cloudflare setup and the request path was simplified so Cloudflare connected directly to the intended origins rather than continuing to traverse Akamai.

Tightening security without breaking legitimate trading traffic

The customer wanted a materially stronger security posture, not a like-for-like migration.

That meant introducing stricter WAF and rate-limiting controls while avoiding false positives that could affect customer logins, trading workflows or other legitimate application traffic.

The migration therefore combined configuration work with observation and tuning. Security controls were hardened progressively as traffic moved to Cloudflare, rather than enabling an aggressive final policy blindly on cutover day.

How Nanosek executed the migration

Four phases, each gated by validation rather than the calendar — with the deadline treated as an engineering constraint from day one.

1
1
Phase 1 Discovery, architecture and behavior mapping
≈ 2 weeks

The first phase focused on understanding what the Akamai estate actually did in production. Nanosek worked through the existing application-delivery and security configuration, documented dependencies and created the target Cloudflare architecture — the migration baseline used for implementation and acceptance testing.

Key activities
- Inventoried the 101 production domains
- Documented Akamai CDN and security behavior
- Mapped application and origin dependencies
- Translated caching requirements into Cloudflare cache controls
- Mapped WAF, bot-management and rate-limiting requirements
- Reviewed DNS and certificate dependencies
- Identified behaviors requiring Transform Rules, Rulesets or Workers
- Designed the staged cutover and rollback approach
- Designed the Magic Transit component for Layer 3 protection
2
2
Phase 2 Staging and parallel validation
≈ 2 weeks

Cloudflare was introduced in stages rather than replacing Akamai immediately. Nanosek onboarded the staging environment and prepared CNAME-based proxying for the production zones, so selected records could be tested through Cloudflare while the existing Akamai service remained available. Issues were corrected before a zone entered its final production state.

Validated per zone
- Origin connectivity
- TLS behavior
- Cache behavior
- Request and response headers
- Redirects
- DNS behavior
- WAF actions
- Bot controls
- Rate limits
- Application-specific exceptions
3
3
Phase 3 Full Cloudflare cutover
≈ 2 weeks

After the staged configuration passed validation, production zones were moved to the full Cloudflare architecture. Akamai was removed from the active delivery path and Cloudflare connected directly to the customer’s origin infrastructure. The security policy was deliberately tuned against observed production traffic so protection could increase without avoidable disruption for legitimate users.

Completed and hardened
- Cloudflare WAF policies
- Custom security rules
- Bot-management controls
- Rate limiting
- Cache Rules
- Redirects
- Transform Rules
- DNS and proxy configuration
- Origin behavior
- Magic Transit for Layer 3 protection
4
4
Phase 4 Post-migration optimization and managed support
Ongoing

The migration did not end when the last domain moved. Nanosek continued to monitor and tune the environment after cutover — security adjustments, application changes and performance optimization — as the Cloudflare deployment settled into normal production operation, under a 15-minute response SLA.

Beyond the original scope
- A 15-minute response SLA established for operational support
- Continuous security tuning against live traffic
- Performance optimization as the deployment settled
- Two Cloudflare Workers developed for a new customer branding campaign — using the new edge platform for application logic, not just delivery and security

Architecture of the migration

Risk lived in one topology, the future in another

The transition deliberately separated migration risk from final-state architecture. During staging, Cloudflare sat in front of selected traffic with Akamai retained behind it as a fallback; the final state removed the intermediary layer entirely.

Migration architecture

The staged topology separated migration risk from final-state architecture.

All 101 domains behind Akamai

Users reached the applications through Akamai, which fronted the whole estate — CDN, WAF and bot controls included. The platform was under regular automated abuse and attack traffic, and the Akamai agreement had a fixed expiry date, so the replacement had to be live before the contract ran out.

101 production domainsRegular attack trafficContract expiry ahead

The staged design gave the engineering team a way to validate Cloudflare with realistic traffic while preserving an escape path. The final architecture then removed the unnecessary intermediary layer — Cloudflare connects directly to the intended origins, with Magic Transit protecting network-layer traffic alongside.

Results

Every figure below is client-reported and reflects the engagement as delivered.

101 / 101

All production domains migrated without reported downtime

Every domain was transitioned within the required migration window without a planned maintenance event or reported migration downtime.

On deadline

Completed before the Akamai contract expired

The project finished before the existing Akamai agreement ended — avoiding an extension of the legacy service purely to buy migration time, and preventing unnecessary commercial overlap.

Hardened

Stronger application-security controls

The final deployment introduced hardened WAF policies, bot-management controls and rate limiting tailored to production traffic. The customer reported no security breaches during the first year following the migration.

Layer 3

Additional network-layer protection

Cloudflare Magic Transit extended the design beyond CDN and application-layer controls, adding protection for network-layer traffic as part of the broader security architecture.

Faster

Improved delivery performance

Following migration and tuning, the customer observed improved response times and lower delivery latency across the production environment.

15-min SLA

Faster operational response

Nanosek established a 15-minute support-response SLA and continued to optimize the environment after migration rather than treating cutover as the end of the engagement.

What made the migration successful

We migrated behavior, not vendor syntax

The most important technical decision was not attempting to reproduce Akamai configuration line by line. The team documented what each existing control was intended to achieve and then selected the appropriate Cloudflare primitive — reducing the risk of carrying legacy design decisions into the new platform simply because they existed in the old one.

The fallback path was part of the design

Rollback was not treated as an emergency document to be written shortly before cutover. The staged topology kept Akamai available while Cloudflare behavior was being validated, giving the team an operational fallback during the highest-risk part of the project.

Security tuning happened against real traffic

Aggressive WAF and rate-limiting policies are useful only when legitimate traffic continues to work. The team used staged traffic and production observations to harden controls progressively, allowing the security posture to improve without turning the migration itself into an availability risk.

The deadline influenced the architecture

The two-month deadline and Akamai contract-expiry date were treated as engineering constraints from the beginning. Discovery, staging, validation and cutover were structured around them rather than hoping configuration work would finish early enough.

Lessons from a 101-domain Akamai migration

What we’d tell any team planning a large multi-domain move between edge platforms.

Akamai to Cloudflare mapping guide

1

Build an application-behavior inventory before touching DNS

Large CDN migrations fail when teams discover important redirects, cache exceptions, origin rules or application dependencies after traffic has already moved. For this project, the existing delivery and security behavior was documented before the production cutover sequence began.
2

Do not assume equivalent products use equivalent controls

Akamai Property Manager behavior, Cloudflare Rulesets, Cache Rules, Transform Rules and Workers solve overlapping problems but are not interchangeable configuration formats. The target design should take advantage of the destination platform instead of recreating the source platform unnecessarily.
3

Parallel validation reduces migration risk

Keeping the old provider available during staged testing gave the team space to investigate unexpected behavior without forcing a rollback under pressure.
4

Post-cutover ownership matters

The first days after a large CDN migration often reveal edge cases that were difficult to reproduce during pre-production testing. Continuous support, log analysis and tuning were therefore included as part of the migration rather than handed off immediately after the final DNS change.

Technology used

Cloudflare CDNCloudflare DNSCloudflare Web Application FirewallCloudflare Bot ManagementCloudflare Rate LimitingCloudflare Cache RulesCloudflare Transform RulesCloudflare WorkersCloudflare Magic TransitAkamai CDN and security services during the migration period

Client identity is withheld at the customer’s request. The figures and outcomes above are client-reported and reflect the engagement as delivered.

Akamai to Cloudflare migration service Cloudflare CDN migration methodology Akamai to Cloudflare mapping guide

Need to migrate from Akamai to Cloudflare?

A CDN migration is rarely just a DNS change. The difficult work is preserving application behavior, security controls, caching, origin logic and operational visibility while traffic moves between platforms.

Nanosek designs and executes staged migrations from Akamai and other edge platforms to Cloudflare, including discovery, configuration mapping, implementation, validation, rollback planning, production cutover and post-migration optimization.

Talk to Nanosek about a migration CDN migration methodology