Akamai migration

Akamai to Cloudflare, behavior by behavior.

Tap any Akamai product to focus the mapping.

Akamai → Cloudflare migration

From Property Manager, through Discovery → Mapping → Cutover → Operate, into the Cloudflare destinations on the right.

Plan your migration View migration checklist

AI summary Machine-readable context is available at /ai-index.json

Nanosek provides Akamai to Cloudflare migration services for enterprises moving CDN, WAF, bot protection, API security, certificates, edge logic, redirects, logging, and operational workflows from Akamai to Cloudflare. The service includes discovery, configuration mapping, Cloudflare target architecture, staged implementation, testing, cutover planning, rollback design, and managed Cloudflare operations after launch.

cloudflare migration akamai cloudflare migration

Why migrate from Akamai to Cloudflare

Migration decisions are driven by consolidation goals, operational complexity, and the need to modernize edge architecture — not just product feature comparisons.

Single platform consolidation

Replace separate Akamai CDN, Kona Site Defender, Bot Manager, EdgeWorkers, and certificate management with Cloudflare CDN, WAF, Bot Management, Workers, API Shield, Zero Trust, and observability under one policy model and one billing relationship.

Reduced operational complexity

Akamai Property Manager rule complexity accumulates over years of incremental changes. Cloudflare Rulesets, Cache Rules, and Transform Rules offer a cleaner declarative model with Terraform, Wrangler, and API-first configuration management.

Faster deployment cycles

Cloudflare rule changes deploy globally in seconds without Akamai activation delays. Terraform and the Cloudflare API support infrastructure-as-code workflows for edge configuration that Property Manager does not support cleanly.

Modern edge logic model

Cloudflare Workers replaces Akamai EdgeWorkers with a V8 JavaScript runtime, built-in KV and Durable Objects storage, and tight integration with Rulesets. Many EdgeWorker use cases can be replaced entirely with declarative rules rather than custom code.

Improved security operations

Cloudflare WAF, Bot Management, API Shield, DDoS protection, and security events are unified in one dashboard with GraphQL analytics, Logpush exports, and SIEM integration — giving security teams better visibility than split Akamai security products.

Path to managed operations

After migration, Nanosek can operate Cloudflare as a managed service with change control, monitoring, incident response, WAF tuning, and ongoing optimization. Cloudflare's API-first design makes managed operations practical at scale.

What we migrate

Each Akamai workstream requires its own mapping, test plan, and cutover sequence. None of them can be assumed to be a direct lift-and-shift.

Property Manager rules

Behaviors, match criteria, and activation logic mapped to Cloudflare Rulesets, Cache Rules, Origin Rules, and Transform Rules. No automated translator exists — each behavior is mapped deliberately.

Cache behaviors and TTL logic

Cache hierarchies, SureRoute equivalents, custom cache keys, TTL policies, serve-stale, and bypass conditions translated to Cloudflare Cache Rules, Cache Reserve, and Tiered Cache topology.

Origin routing and failover

Akamai origin server groups, failover priorities, and health check logic mapped to Cloudflare Load Balancing, Origin Rules, Host Header override, and health check monitors.

Redirects and URL rewrites

Edge Redirector rules and URL manipulation behaviors translated to Cloudflare Redirect Rules and Transform Rules. Complex conditional logic handled by Cloudflare Workers where needed.

EdgeWorkers and edge logic

Each EdgeWorker reviewed for functional equivalence. Behavior-first replacements with declarative rules preferred; complex logic ported to Cloudflare Workers with output validation.

Kona Site Defender WAF

Managed rules, custom signatures, exception lists, IP lists, rate limits, and enforcement modes mapped to Cloudflare WAF Managed Rules, Custom Rules, Rate Limiting, and IP Lists.

Bot Manager policies

Bot detection categories, challenge types, score thresholds, and allowlists mapped to Cloudflare Bot Management or Super Bot Fight Mode depending on plan. Known-bot allowlisting reviewed before enforcement.

API security controls

Akamai API Gateway protections, rate limits, and authentication controls translated to Cloudflare API Shield, mTLS, schema validation, and abuse rate rules.

Certificates and hostnames

All hostnames, SNI requirements, custom certificates, and origin cert chains reviewed and prepared for Cloudflare Universal SSL, Advanced Certificate Manager, or custom certificate upload.

DNS onboarding and cutover

Full zone or CNAME (partial zone) onboarding plan with TTL reduction, staged hostname cutover, propagation monitoring, and rollback decision points documented in advance.

Log delivery and SIEM

Akamai DataStream log delivery replaced with Cloudflare Logpush datasets, field normalization, destination configuration, and SIEM parser updates before DataStream is decommissioned.

Operational runbooks

Akamai activation workflows, alerting, escalation paths, and change procedures replaced with Cloudflare-native equivalents and handover documentation for the operations team.

Akamai to Cloudflare mapping

Every Akamai area has a Cloudflare target. The migration work is in the configuration translation and validation — not just the product swap.

Akamai area	Cloudflare target	Migration notes
Property Manager rules	Rulesets, Cache Rules, Origin Rules, Transform Rules, Configuration Rules	No automated translation. Each behavior requires an explicit mapping decision.
Cache behaviors	Cache Rules, Cache Reserve, Tiered Cache, custom cache keys	Akamai SureRoute and cache hierarchy require explicit Tiered Cache topology planning.
Origin selection and failover	Load Balancing, Origin Rules, Host Header override, SNI controls	Origin server groups and failover logic map to Load Balancing pools with health checks.
Redirects and URL rewrites	Redirect Rules, Transform Rules, Workers where needed	Edge Redirector bulk redirects map to Redirect Rules. Conditional URL logic may need Workers.
EdgeWorkers	Cloudflare Workers	V8 JavaScript runtime is comparable. Behavior-first review determines rules vs Workers per use case.
Kona Site Defender	WAF Managed Rules, Custom Rules, Rate Limiting, IP Lists	Managed rules, exceptions, and IP reputation require normalization. Enforce in log mode first.
Bot Manager	Bot Management or Super Bot Fight Mode	Bot Management tier depends on Cloudflare plan. Known-bot allowlisting required before enforcement.
API protection	API Shield, mTLS, schema validation, rate limiting	Akamai API Gateway endpoints must be re-discovered and re-protected in API Shield.
Log delivery (DataStream)	Logpush, GraphQL Analytics API, Security Events	Log schemas differ. Logpush fields, destinations, and SIEM parsers require normalization.
Certificates	Universal SSL, Advanced Certificate Manager, custom certs, origin certs	Certificate validation must complete before DNS cutover. Plan for provisioning time.
DNS traffic shift	Cloudflare DNS, partial/full zone onboarding, staged cutover	CNAME onboarding supports hostname-by-hostname migration without full NS delegation.

Migration methodology

Each phase has defined inputs, outputs, and approval criteria. No phase begins until the previous one is validated.

Phase 1

Discovery and export review

Collect Akamai properties, hostnames, behaviors, certificates, origins, WAF policies, bot rules, EdgeWorkers, redirects, and DataStream configuration.
Identify business-critical paths: APIs, login flows, payment flows, third-party integrations, static asset paths, and monitoring dependencies.
Document current-state baselines: performance metrics, WAF event rates, bot traffic volumes, cache hit ratios, and origin error rates.

Phase 2

Mapping and target architecture

Translate each Akamai behavior category to Cloudflare primitives. Decide what becomes declarative rules vs Cloudflare Workers.
Define zone model, DNS onboarding method (full zone vs CNAME), certificate strategy, security model, and observability architecture.
Produce a mapping workbook covering every Akamai rule, its Cloudflare equivalent, open decisions, and implementation owner.

Phase 3

Build and shadow validation

Configure Cloudflare in a test zone, partial traffic routing, or staging DNS environment while Akamai remains active.
Deploy WAF and Bot Management in log mode — no blocking, no challenges. Review events against traffic baselines.
Validate cache behavior, headers, redirects, origin connectivity, SNI alignment, and application flows per critical path.

Phase 4

Cutover preparation

Reduce DNS TTLs to 60–300 seconds at least 48 hours before the cutover window.
Complete certificate provisioning on Cloudflare. Pre-validate all hostnames before touching DNS.
Write rollback runbook: DNS reversion steps, timing constraints, responsible owners, and rollback decision triggers.
Define monitoring window, alert thresholds, and get written stakeholder approval for the cutover schedule.

Phase 5

Production cutover

Move traffic gradually using CNAME onboarding or weighted DNS where hostname-by-hostname migration is possible.
Monitor HTTP error rates, cache hit ratio, origin health, WAF events, bot events, latency, and business flows in real time.
Execute rollback immediately if defined thresholds are breached or stakeholder approval is withdrawn.

Phase 6

Optimization and managed operations

Promote WAF and bot controls from log mode to enforce mode with false-positive tuning based on observed traffic.
Optimize cache rules, add Tiered Cache topology, review cache hit ratios and TTL settings, configure Cache Reserve where appropriate.
Configure Logpush destinations, validate SIEM delivery, and build security dashboards and alerting.
Transition to change-control and managed Cloudflare operations. Schedule Akamai property deactivation and contract review.

Important migration decisions

These decisions affect architecture, enforcement timing, cutover risk, and long-term operability. They must be resolved in Phase 2 before build work begins.

Full zone vs partial CNAME onboarding

Full zone onboarding delegates DNS to Cloudflare and unlocks all features. CNAME onboarding keeps DNS elsewhere and lets you migrate hostname-by-hostname. The right choice depends on DNS ownership, internal team structure, and cutover risk tolerance.

Static rules vs Cloudflare Workers

Declarative rules (Cache Rules, Transform Rules, Redirect Rules) are simpler to maintain and harder to break. Workers provide full flexibility but add operational complexity. Evaluate each EdgeWorker use case independently — rules first, Workers when necessary.

Cache behavior compatibility

Some Akamai cache behaviors have no exact Cloudflare equivalent. Tiered Cache topology, custom cache keys, and Cache Reserve each require explicit configuration decisions. Migration is an opportunity to simplify caching rather than replicate Akamai complexity.

WAF enforcement timing

Deploying directly to blocking mode increases cutover risk. Log mode review, exception tuning, and graduated promotion to blocking reduces false-positive risk while maintaining rollback at every step. Plan 2–4 weeks of log mode review before blocking.

Bot mitigation thresholds

Bot Management score thresholds for challenge vs block must be calibrated against real application traffic. Aggressive thresholds risk blocking legitimate users; conservative thresholds miss bot activity. Calibrate in log mode before any enforcement.

Origin SNI and Host header alignment

Cloudflare uses different default SNI and Host header forwarding behavior than Akamai. Origin certificate validation, virtual hosting, and multi-origin properties all require explicit SNI and Host header controls configured and tested before cutover.

Certificate strategy

Cloudflare Universal SSL, Advanced Certificate Manager, and custom certificate upload each have different validation timelines, wildcard coverage, and operational requirements. Certificate provisioning must complete before DNS moves — plan the lead time.

Logpush and SIEM requirements

Cloudflare Logpush field names, schemas, and dataset structure differ from Akamai DataStream. SIEM normalization rules must be updated and tested before Akamai logging is decommissioned — otherwise security monitoring goes dark during the transition.

Terraform and API automation

Cloudflare supports Terraform, the Cloudflare API, and Wrangler for infrastructure-as-code. Rebuilding Akamai Property Manager configurations in Terraform during migration modernizes configuration management and reduces manual error risk going forward.

Rollback strategy

Every production cutover needs a documented rollback plan: DNS reversion steps, certificate fallback, timing constraints, and responsible owners. Rollback becomes harder once TTLs propagate and Akamai contracts are scheduled for termination.

Risks and mitigations

Risk	Mitigation
Cache behavior mismatch after cutover.	Test cache rules per critical path in the Cloudflare staging environment. Compare cache hit ratios and origin request volumes against Akamai baselines before and after traffic moves.
Broken redirects or URL rewrites.	Build a redirect test matrix from Akamai Edge Redirector exports. Run automated validation against the Cloudflare zone before cutover. Confirm all business-critical redirects match expected behavior.
WAF false positives blocking legitimate users.	Deploy WAF in log mode, review events against known-good traffic, build exceptions for legitimate patterns, and promote to block mode in stages over 2–4 weeks.
Bot protection challenging real users or partners.	Review bot scores in log mode. Add allowlists for known crawlers, monitoring agents, partners, and internal automation before enabling any challenge or block action.
Origin SNI or Host header mismatch.	Validate origin connectivity with explicit SNI and Host header settings in Cloudflare before DNS migration. Test origin certificate chains and virtual host routing for each origin.
Certificate validation delays blocking cutover.	Start certificate provisioning 24–48 hours before cutover. Pre-validate all hostnames on Cloudflare. Do not proceed with DNS changes until all certificates show active status.
DNS propagation extending rollback window.	Reduce TTLs to 60–300 seconds at least 48 hours before cutover. Use CNAME onboarding where possible to enable per-hostname cutover and independent rollback per hostname.
Missing logs and broken SIEM pipelines.	Configure Logpush and validate delivery to SIEM before Akamai DataStream is decommissioned. Update SIEM field mappings, test alert rules, and verify detection coverage against known event types.
EdgeWorker logic not fully mapped to Cloudflare Workers.	Review each EdgeWorker in Phase 1 with a function-by-function behavioral audit. Test Workers output against Akamai EdgeWorker output for each use case before any traffic is moved.

Pre-cutover validation checklist

All items must be confirmed before production traffic moves to Cloudflare. Any unresolved item is a reason to delay.

DNS records and TTLs reviewed and reduced to 60–300 seconds
Certificates active and valid on all hostnames in Cloudflare
Origin connectivity tested from Cloudflare edge for each origin
Host header and SNI behavior validated per origin server
Cache rules tested per critical path against expected TTLs
Redirects and URL rewrites validated against test matrix
Login, checkout, API, and file upload flows tested end-to-end
WAF events reviewed in log mode — false positives identified and resolved
Bot scores and challenge behavior reviewed against traffic baseline
Rate limits tested safely using synthetic or internal traffic
HTTP error rates compared against Akamai baseline metrics
Logpush delivery confirmed to SIEM or analytics destination
Rollback steps documented with owner, timing, and trigger criteria
Stakeholders approved cutover window, monitoring plan, and escalation path

Deliverables

Akamai current-state inventory
Akamai-to-Cloudflare mapping workbook
Cloudflare target architecture document
Rule translation plan
WAF and bot migration plan
Cache and origin behavior test matrix
Cutover runbook
Rollback runbook
Validation and testing report
Post-launch tuning backlog
Managed operations handover documentation

Frequently asked questions

How long does an Akamai to Cloudflare migration take?

Timelines depend on property count, configuration complexity, WAF rules, and stakeholder alignment. A focused migration for a single application can take 4–8 weeks. A full estate migration across many properties, security policies, and operational workflows typically takes 3–6 months in structured phases.

Can Akamai Property Manager rules be migrated automatically?

No automated tool converts Akamai Property Manager behaviors directly to Cloudflare rules. Each behavior category requires manual mapping decisions across Cache Rules, Origin Rules, Transform Rules, Redirect Rules, and Cloudflare Workers. Nanosek builds a mapping workbook from your property export and translates rules deliberately, not automatically.

Do we need Cloudflare Workers to replace Akamai EdgeWorkers?

Not always. Many Akamai EdgeWorker use cases — redirects, header manipulation, request routing — can be handled by declarative Cloudflare rules. Complex EdgeWorker logic with conditional flows, external API calls, or dynamic decisions may require Cloudflare Workers. Nanosek reviews each EdgeWorker and recommends rules vs Workers based on behavior complexity and maintainability.

Can Cloudflare match Akamai caching behavior?

Yes in most cases. Cloudflare Cache Rules support cache-key customization, TTL overrides, bypass conditions, serve-stale, and tiered caching. The important work is mapping Akamai SureRoute, cache hierarchy, and custom cache keys to Cloudflare equivalents — including Cache Reserve and Tiered Cache — and validating cache hit rates after migration.

How do you reduce WAF and bot false positives?

Nanosek deploys WAF and Bot Management in log or simulate mode first. Security events are reviewed against known-good traffic patterns over 2–4 weeks. Exceptions and score thresholds are adjusted before enforcement is enabled. WAF managed rules are promoted to block mode gradually, with rollback available at each step.

Can migration happen without downtime?

Yes. DNS-based migration supports TTL reduction and staged traffic movement. Certificates are pre-validated on Cloudflare before any DNS changes are made. Cloudflare CNAME onboarding (partial zone) allows traffic to move hostname-by-hostname without a full DNS cutover. Rollback paths are documented and tested before production traffic moves.

Can we keep Akamai and Cloudflare running in parallel during testing?

Yes. Parallel operation is standard practice during validation. Cloudflare can serve test traffic or specific hostnames while Akamai continues to serve production traffic. This allows cache behavior, security controls, origin connectivity, and application flows to be validated against real traffic before committing to a cutover window.

What happens after cutover?

Post-cutover work includes WAF and bot control tuning, cache optimization, Logpush configuration, security dashboard setup, alerting, and Akamai contract wind-down planning. Nanosek provides a post-launch tuning backlog and can continue as a managed Cloudflare operations partner.

Can Nanosek manage Cloudflare after migration?

Yes. Nanosek provides managed Cloudflare operations as a Cloudflare authorized MSP and ASDP partner. This covers configuration management, security tuning, change control, incident response, monitoring, and ongoing optimization — starting immediately after cutover.

Plan your Akamai to Cloudflare migration

Nanosek can design and deliver a migration plan that fits your Akamai estate, timeline, risk tolerance, and operational model.

Get in Touch View Migration Checklist