✏️ Click any text to edit it — changes save when you download
Cloudflare · Deployment Plan Overview

From Akamai
to Cloudflare
in 6 Weeks

A structured migration path for Dollar General's five current Akamai products — scoped, phased, and designed to run in parallel with zero downtime.
Account
Dollar General Corp.
NYSE: DG
Target Timeline
4–6 Weeks
Weeks 1–6 from kickoff
Renewal Window
September 2026
Akamai contract end
Deployment Model
Parallel / No Downtime
Shadow mode first, cutover last
What's Moving
Five Products. One Migration.
Current (Akamai)Replacement (Cloudflare)Phase
App & API Protector (WAF) → Advanced WAF + DDoS Managed Rules Phase 2
Protect & Perform SOA (CDN) → Cloudflare CDN + Cache Rules Phase 1
Edge Redirector Cloudlet → Bulk Redirects + Transform Rules Phase 3
EdgeWorkers → Cloudflare Workers Phase 4
DataStream 2.0 → Logpush Phase 5
Timeline Overview
Weeks 1–2
Zone Setup
& DNS
Weeks 2–3
WAF
Configuration
Week 3–4
Redirects
Migration
Week 4–5
Workers
Migration
Week 5–6
Logpush
+ Cutover
Deployment Phases
Phase 1
Wks 1–2
Zone Onboarding & CDN Foundation
Bring DG's zones into Cloudflare without touching traffic — zero risk, parallel setup
Products
Cloudflare CDN Cache Rules SSL/TLS
Add DG's zones to Cloudflare dashboard; import existing DNS records from Akamai configuration
Provision Universal SSL certificates — automatic, no manual CSR process
Set Cloudflare proxy to DNS-only mode (gray-cloud) — Akamai remains live during this phase
Configure CDN cache rules to match current Akamai Protect & Perform SOA caching behavior
Set up performance settings: Argo Smart Routing, HTTP/3, compression rules
Validate zone configuration in staging environment before any traffic shift
→ Deliverable: All DG zones mirrored in Cloudflare, SSL active, CDN rules configured. Akamai still serving all traffic. No customer impact possible.
Phase 2
Wks 2–3
WAF Configuration & Validation
Deploy WAF in Log mode first — review, tune, block. No traffic moves until rules are validated
Products
Advanced WAF Managed Rules DDoS Protection
Enable Cloudflare WAF Managed Ruleset (OWASP Core + Cloudflare Managed) in Log mode — monitors without blocking
Review Akamai App & API Protector rule export; map custom rules to Cloudflare custom WAF rule equivalents
Analyze Log mode traffic for false positives — tune rule overrides before switching to Block
Enable DDoS Managed Rules (L7) — active protection, no tuning required
Configure WAF rate limiting rules matching current Akamai rate control policies
Switch WAF from Log to Block mode after false positive review — typically 5–7 days of log data sufficient
→ Deliverable: WAF running in Block mode, tuned to DG's traffic profile. Managed Rules active. DDoS protection on. Log mode data reviewed by DG security team (Barrows/Lawson).
Phase 3
Wks 3–4
Redirects Migration
Export Edge Redirector rules from Akamai; bulk import into Cloudflare — typically hours, not days
Products
Bulk Redirects Transform Rules
Export all Edge Redirector Cloudlet rules from Akamai as CSV — no manual re-entry required
Import into Cloudflare Bulk Redirects via CSV upload — supports hundreds of thousands of rules at account level
Map any dynamic redirect logic (conditional, regex-based) to Cloudflare Transform Rules
Test all redirect paths in staging before DNS cutover — Validate rule-for-rule parity
→ Note: Bulk Redirects operates at the account level — no per-zone configuration needed for large redirect sets. Confirm with : total redirect rule count from Akamai export.
Phase 4
Wks 4–5
EdgeWorkers → Workers Migration
Both run JavaScript at the edge — migration is a rewrite, not a rebuild. Complexity depends on what the EdgeWorkers are doing
Products
Workers Workers KV
Inventory all active EdgeWorkers in DG's Akamai account — document function, trigger, and traffic volume for each
Rewrite EdgeWorker logic to Workers API — same language (JS/TS), different runtime APIs (fetch, cache, KV vs. Akamai primitives)
Deploy Workers in dry-run mode alongside Akamai EdgeWorkers — compare outputs before cutover
Migrate any EdgeWorker state storage to Workers KV or Durable Objects as appropriate
→ Timeline variable: Simple EdgeWorkers (A/B testing, header manipulation, redirects) migrate in hours. Complex logic (personalization engines, API orchestration) may require 2–3 weeks. SE to review DG's EdgeWorker inventory before confirming timeline.
Phase 5
Wks 5–6
Logpush Configuration & DNS Cutover
Replace DataStream 2.0 with Logpush, validate log continuity, then flip the DNS switch
Products
Logpush DNS Cutover
Configure Logpush jobs to match DG's current DataStream 2.0 destinations (S3, Splunk, or equivalent SIEM)
Run Logpush in parallel with DataStream for 48–72 hours — validate field parity before switching SIEM ingestion
Update DNS nameservers or CNAME records to route traffic through Cloudflare proxy (gray-cloud → orange-cloud)
Monitor traffic, error rates, cache hit ratio, and WAF block rates for 24 hours post-cutover
Akamai contract remains active as fallback — revert DNS in under 5 minutes if needed
→ Deliverable: All DG traffic running through Cloudflare. Logpush feeding the same SIEM DataStream was. Akamai contract on standby. Formal sign-off from Barrows/Lawson before closing out Akamai.
Before This Goes to DG — Confirm with SE
How many hostnames/zones is DG currently running on Akamai? (affects Phase 1 timeline)
What is DG's current EdgeWorker inventory — how many, and what do they do? (determines Phase 4 timeline)
Where does DataStream 2.0 currently push logs? (S3 bucket, Splunk, Sumo Logic, or other SIEM — needed for Phase 5 Logpush config)
Does DG have a maintenance window requirement for the DNS cutover? (affects Phase 5 scheduling)
Are there any Akamai Ion or mPulse RUM features in use that don't have a direct Cloudflare equivalent? (need to surface early)
Dollar General · Cloudflare Deployment Plan Overview · For SE review before customer distribution