Emergency migration

When DNS is on fire, all lanes move at once.

Tap a lane to see what runs in parallel.

◉ INCIDENT IN PROGRESSPARALLEL WORKSTREAMST-MINUS CUTOVERall lanes execute in parallelDNS onboarding0%WAF + DDoS baseline0%Origin lockdown0%Logpush + alerts0%Comms + runbook0%
!

Workstream

WAF + DDoS baseline

Enable Managed Rules in monitor mode, turn on DDoS protection defaults, baseline traffic for false positives.
Request emergency migration support View emergency checklist
On this page
AI summary Machine-readable context is available at /ai-index.json

Nanosek provides emergency Cloudflare migration services for organizations that need urgent production stabilization during DDoS attacks, HTTP floods, CDN or WAF vendor failures, DNS incidents, certificate issues, origin exposure, security events, or high-risk migration windows. The service includes emergency triage, Cloudflare onboarding, DNS and certificate validation, origin reachability checks, WAF and DDoS baseline controls, bot and rate limiting review, Logpush and monitoring setup, cutover support, rollback planning, and post-incident hardening.

cloudflareemergency migrationcdn migrationddos responsewaf onboardingdns cutoverorigin protectionincident response

Who this is for

Security, infrastructure, platform, SRE, application, incident response, and enterprise teams handling urgent production risk.
Organizations facing DDoS attacks, HTTP floods, CDN or WAF failures, DNS incidents, certificate problems, origin exposure, or high-risk cutovers.
Leadership and technical teams that need fast but controlled Cloudflare onboarding, monitoring, rollback, and post-incident hardening.

When emergency Cloudflare migration is needed

Active DDoS or HTTP flood

Cloudflare can help absorb and control attack traffic when onboarding, origin protection, WAF, cache, bot, and rate controls are configured correctly.

Current CDN or WAF provider failure

Nanosek helps establish a Cloudflare delivery and security path when an existing provider is degraded, misconfigured, or unavailable.

Urgent vendor exit or contract deadline

Critical hostnames can be prioritized first, with scope expansion and hardening after production traffic is stable.

Exposed origin under attack

Emergency work can focus on moving traffic behind Cloudflare, validating origin reachability, and reducing direct-to-origin bypass paths.

DNS incident or provider instability

Nanosek reviews DNS authority, records, TTLs, registrar access, nameserver options, and rollback before changes are made.

Certificate expiration or TLS failure

Cloudflare certificate options, SSL/TLS mode, hostname coverage, CAA records, and origin TLS behavior are validated before proxying where possible.

WAF bypass or security exposure

Baseline WAF controls can be introduced carefully while avoiding broad rules that break legitimate users.

Bot or scraping surge

Bot Management, WAF custom rules, verified bot handling, rate limiting, and Turnstile can reduce automation impact after traffic patterns are reviewed.

Application launch under traffic pressure

Cloudflare cache, DDoS readiness, load balancing, observability, and rollback planning can reduce launch-window production risk.

Emergency protection for high-risk campaign

Critical campaign hostnames and paths can be onboarded with conservative cache, WAF, bot, and monitoring controls.

Broken edge configuration

Nanosek helps identify failing redirects, headers, cache behavior, TLS mode, origin routing, or provider-specific rules and rebuild safe Cloudflare equivalents.

Need for rapid rollback-ready Cloudflare onboarding

Emergency migration should keep decision owners, validation signals, and rollback steps visible throughout the incident.

Emergency migration principles

Emergency migrations require speed, but speed without control creates new risk. Nanosek uses a stabilization-first approach: protect the most critical paths, validate the minimum safe configuration, move traffic in a controlled way, monitor behavior, and document rollback before expanding scope.

Stabilize first, optimize laterProtect critical paths before broad tuningPrefer minimal safe configuration over complex changesValidate DNS, TLS, and origin behavior before traffic movesStart WAF and bot controls conservatively where false positives are riskyKeep rollback available whenever possibleDocument decisions during the incidentConvert temporary emergency rules into durable policies after the event

Our emergency Cloudflare migration approach

Phase 1

Rapid triage

  • Identify the incident driver, affected hostnames, business-critical paths, current DNS authority, current CDN/WAF provider, origin endpoints, certificate state, application owners, and rollback constraints.
  • Confirm whether the priority is DDoS stabilization, CDN replacement, WAF onboarding, DNS cutover, certificate recovery, origin protection, or all of these.
Phase 2

Minimum safe Cloudflare architecture

  • Define the fastest safe Cloudflare onboarding path: full zone, partial CNAME, delegated hostname, temporary hostname, or staged cutover.
  • Decide proxy status, SSL/TLS mode, certificate strategy, origin configuration, basic cache behavior, emergency WAF controls, DDoS posture, and logging.
Phase 3

DNS, certificate, and origin validation

  • Validate DNS records, TTLs, certificate coverage, SSL/TLS mode, origin reachability, Host header behavior, SNI behavior, origin firewall rules, and critical paths before production traffic moves.
Phase 4

Emergency security baseline

  • Apply conservative baseline controls for WAF, DDoS, bot mitigation, rate limiting, API protection, and origin protection.
  • Avoid broad blocking on sensitive flows until logs and user impact are understood.
Phase 5

Controlled traffic cutover

  • Move traffic using DNS, CNAME, proxy enablement, or staged routing depending on the situation.
  • Monitor HTTP status codes, TLS errors, origin errors, cache behavior, WAF events, bot events, latency, and critical user journeys.
Phase 6

Stabilization and tuning

  • Review live telemetry, reduce false positives, adjust cache rules, tune WAF or rate limits, validate application behavior, and keep stakeholders updated.
Phase 7

Post-incident hardening

  • Replace temporary emergency rules with durable policies.
  • Create long-term Cloudflare architecture, runbooks, dashboards, alerts, Terraform/API automation, and managed operations backlog.

Architecture

DNS, certificates, origin reachability, cache behavior, and failover paths.
WAF rulesets, custom rules, exceptions, bot signals, API controls, and rate limits.
Identity provider integration, device posture, user groups, tunnels, and access policies where Zero Trust is involved.
Logpush destinations, SIEM fields, alerting, ownership, and retention requirements.

What emergency migration can cover

DNS onboarding and record review

Review current DNS authority, records, TTLs, registrar access, import accuracy, and emergency change path.

Full zone or partial CNAME onboarding

Choose the safest onboarding model based on control, urgency, DNS ownership, and rollback constraints.

Certificate readiness

Validate Universal SSL, Advanced Certificate Manager, custom certificates, CAA records, and hostname coverage.

SSL/TLS mode validation

Confirm edge-to-origin TLS behavior, Full Strict readiness, origin certificates, and backend expectations.

Origin connectivity

Test origin reachability, ports, firewall rules, response behavior, and direct-to-origin exposure.

Host header and SNI alignment

Validate that origins accept Cloudflare traffic with expected Host header, SNI, certificate, and virtual host behavior.

CDN proxy enablement

Proxy critical hostnames through Cloudflare after DNS, TLS, origin, and rollback checks are complete.

Cache baseline rules

Apply conservative cache controls first and avoid dynamic or authenticated caching until behavior is validated.

WAF baseline controls

Enable controlled WAF protection using managed rules, custom rules, or monitoring-first policy depending on false-positive risk.

DDoS protection posture

Review HTTP DDoS posture, cache strategy, origin capacity, and attack-specific telemetry.

Bot and rate limiting controls

Apply bot, challenge, Turnstile, and rate limiting controls carefully around login, checkout, APIs, and search.

API path protection

Identify expensive or abused API paths and add API-specific WAF, rate, mTLS, or API Shield controls where applicable.

Redirect and header behavior

Rebuild only necessary redirect, rewrite, and header behavior needed for safe emergency cutover.

Logpush, analytics, and event monitoring

Enable Cloudflare analytics, Security Events, Logpush where possible, dashboards, and live monitoring.

Cutover and rollback runbook

Document owners, exact changes, decision criteria, validation checks, and rollback sequence before production movement.

Post-incident stabilization backlog

Track temporary controls, hardening tasks, automation, documentation, monitoring, and managed operations follow-up.

Emergency decision matrix

Active DDoS / HTTP flood

First priority

Keep application reachable and protect origin

Cloudflare controls

DDoS protection, WAF, cache rules, rate limiting, bot controls, origin lockdown

CDN provider outage

First priority

Restore delivery path

Cloudflare controls

Cloudflare DNS/proxy, certificates, cache baseline, origin validation

WAF provider failure

First priority

Add controlled security layer

Cloudflare controls

WAF Managed Rules, Custom Rules, Security Events, conservative enforcement

Exposed origin attack

First priority

Prevent bypass traffic

Cloudflare controls

Origin firewall allowlisting, Authenticated Origin Pulls, DNS cleanup, WAF/rate limits

Certificate/TLS failure

First priority

Restore safe HTTPS

Cloudflare controls

Universal SSL, Advanced Certificate Manager, custom certs, Full Strict validation

DNS provider issue

First priority

Move authoritative DNS safely

Cloudflare controls

Zone import, record validation, nameserver cutover, rollback nameservers

Bot surge

First priority

Reduce automation impact

Cloudflare controls

Bot Management, verified bots, WAF rules, rate limiting, Turnstile where appropriate

API abuse

First priority

Protect expensive endpoints

Cloudflare controls

API-specific WAF rules, rate limiting, API Shield, mTLS where applicable

High-risk launch

First priority

Prepare for traffic spike

Cloudflare controls

Cache strategy, DDoS readiness, load balancing, monitoring, rollback plan

Vendor exit deadline

First priority

Migrate with minimum risk

Cloudflare controls

Discovery, mapping, staged cutover, validation, post-launch hardening

Deployment steps

  1. 01 Confirm incident driver, affected hostnames, critical paths, business owners, DNS authority, provider dependencies, and rollback constraints.
  2. 02 Choose a minimum safe Cloudflare onboarding model and prepare zone, hostname, DNS, certificate, proxy, and origin configuration.
  3. 03 Validate DNS, SSL/TLS, origin reachability, Host header, SNI, firewall rules, cache baseline, and critical application flows.
  4. 04 Apply conservative emergency WAF, DDoS, bot, rate limiting, API, and origin controls based on incident evidence.
  5. 05 Cut over approved traffic with live monitoring of status codes, TLS errors, origin errors, cache behavior, WAF events, bot events, latency, and user journeys.
  6. 06 Tune controls during stabilization and keep a visible incident change log, validation notes, and stakeholder updates.
  7. 07 Convert the emergency setup into durable Cloudflare architecture, runbooks, dashboards, automation, and managed operations.

Risks and mitigations

Risk

Moving too fast creates outage

Mitigation

Use minimum safe configuration, validate DNS/TLS/origin first, and cut over only approved hostnames.

Risk

Certificate not ready

Mitigation

Validate Universal SSL, Advanced Certificate Manager, or custom certificate coverage before proxying.

Risk

Origin rejects Cloudflare traffic

Mitigation

Validate Host header, SNI, firewall rules, TLS mode, ports, and backend expectations.

Risk

WAF blocks real users

Mitigation

Start with conservative actions, review Security Events, and scope emergency blocks carefully.

Risk

Cache behavior breaks application

Mitigation

Start with baseline cache behavior and avoid caching dynamic/authenticated content blindly.

Risk

DNS rollback unclear

Mitigation

Document previous records, nameservers, TTLs, and rollback conditions before cutover.

Risk

Missing visibility during incident

Mitigation

Enable Cloudflare analytics, Security Events, Logpush where possible, and live monitoring.

Risk

Origin remains exposed

Mitigation

Lock down origin access to Cloudflare and remove unintended direct DNS exposure.

Risk

Temporary rules become permanent

Mitigation

Add owner, reason, expiry, and post-incident review for all emergency controls.

Risk

Stakeholders lose alignment

Mitigation

Maintain clear decision owners, change log, validation results, and next steps.

Emergency validation checklist

  • Incident driver confirmed
  • Critical hostnames identified
  • Critical paths identified
  • DNS authority confirmed
  • Registrar access confirmed, if needed
  • Existing DNS records exported
  • Cloudflare zone or hostname prepared
  • Proxy status decided
  • Certificates issued or uploaded
  • SSL/TLS mode validated
  • Origin IPs and hostnames confirmed
  • Origin reachability tested
  • Host header behavior validated
  • SNI behavior validated
  • Origin firewall rules reviewed
  • Cache baseline configured
  • WAF baseline configured
  • Bot and rate limiting approach reviewed
  • API paths identified
  • Log visibility enabled
  • Monitoring window assigned
  • Rollback path documented
  • Decision owners identified
  • Production cutover approved

Deliverables

  • Emergency triage summary
  • Critical hostname and path inventory
  • Minimum safe Cloudflare architecture
  • DNS and certificate validation notes
  • Origin connectivity validation
  • Emergency WAF and DDoS baseline
  • Bot and rate limiting recommendations
  • Cutover runbook
  • Rollback runbook
  • Live validation notes
  • Incident change log
  • Post-incident hardening roadmap
  • Managed operations handover

What happens after stabilization

Emergency onboarding should not become the final architecture by accident. After traffic is stabilized, Nanosek helps convert the emergency setup into a durable Cloudflare environment.

Review emergency changes
Remove unnecessary temporary rules
Tune WAF and bot controls
Improve cache strategy
Lock down origins
Add Logpush and dashboards
Document DNS and certificate ownership
Build Terraform/API automation
Prepare standard operating runbooks
Transition into Cloudflare Managed Services

Emergency vs standard migration

Goal

Emergency migration

Stabilize production quickly

Standard migration

Migrate with full discovery and optimization

Scope

Emergency migration

Critical hostnames and paths first

Standard migration

Complete platform migration

Timing

Emergency migration

Incident-driven or urgent

Standard migration

Planned project timeline

WAF posture

Emergency migration

Conservative baseline first

Standard migration

Detailed policy mapping and tuning

Cache posture

Emergency migration

Safe baseline first

Standard migration

Full cache behavior translation

Documentation

Emergency migration

Change log and immediate runbooks

Standard migration

Full architecture and migration workbook

Optimization

Emergency migration

After stabilization

Standard migration

During migration planning and build

Rollback

Emergency migration

Required where possible

Standard migration

Designed before cutover

Follow-up

Emergency migration

Post-incident hardening

Standard migration

Post-launch optimization

When Nanosek should help

You need urgent Cloudflare onboarding during an attack or outage.
Your current CDN, DNS, or WAF provider is failing.
Your origin is exposed and under pressure.
You need to move critical traffic quickly but safely.
You need emergency WAF, DDoS, bot, or rate limiting controls.
You need DNS, certificate, and origin validation under time pressure.
You need a rollback-aware cutover plan.
You need post-incident hardening and managed Cloudflare operations.

Frequently asked questions

What is an emergency Cloudflare migration?
An emergency Cloudflare migration is a rapid, controlled onboarding of critical applications or hostnames to Cloudflare during an urgent incident, attack, outage, vendor failure, certificate problem, or high-risk cutover window.
Can emergency migration happen without downtime?
Nanosek plans emergency migrations to reduce downtime risk, but no emergency migration should promise zero downtime. Risk depends on DNS control, certificate readiness, origin behavior, application complexity, current incident conditions, and rollback options.
What is the first thing Nanosek checks?
Nanosek first identifies the incident driver, affected hostnames, DNS authority, certificate state, origin reachability, business-critical paths, current provider dependencies, and rollback constraints.
Can Cloudflare help during a DDoS attack?
Yes. Cloudflare can provide DDoS protection and application-layer controls, but effective response also depends on correct onboarding, origin protection, WAF and rate limiting design, logging, and live tuning.
Can you migrate only one hostname first?
Yes. In many emergency cases, it is safer to migrate only the most critical hostname or path first, validate behavior, and then expand scope after stabilization.
What if our DNS is not managed by Cloudflare?
Nanosek can help evaluate full zone onboarding, partial CNAME onboarding, temporary CNAME cutover, or staged DNS changes depending on registrar access, DNS ownership, and urgency.
What if certificates are not ready?
Certificate readiness is a critical gate. Nanosek validates Universal SSL, Advanced Certificate Manager, custom certificates, CAA records, and SSL/TLS mode before production traffic is proxied where possible.
Will WAF rules be enabled immediately?
Emergency WAF controls should be applied carefully. Nanosek usually starts with conservative baseline protection and promotes rules based on traffic evidence, attack pattern, and false-positive risk.
What happens after the emergency?
After stabilization, Nanosek helps review temporary changes, tune policies, harden origins, add observability, document runbooks, and transition the environment into a durable Cloudflare operating model.
Can Nanosek manage Cloudflare after emergency migration?
Yes. Nanosek provides managed Cloudflare operations, including DNS changes, WAF and bot tuning, DDoS readiness, cache optimization, Logpush monitoring, incident support, reporting, and continuous improvement.

Stabilize urgent traffic on Cloudflare

Nanosek helps you move quickly without losing control with emergency Cloudflare onboarding, validation, monitoring, rollback planning, and post-incident hardening.

Talk to Nanosek View managed Cloudflare services
Ready to talk?

Deliver Cloudflare without surprises.

Whether you're migrating, hardening, or operating Cloudflare — Nanosek brings authorized MSP & ASDP delivery, rollback-ready cutovers, and managed operations after launch.

Talk to Nanosek Run readiness assessment