Home/Server & Website Managed Operations/ICP Filing Modification, Cancellation, and Accession: Key Points and Common Errors
Server & Website Managed Operations

ICP Filing Modification, Cancellation, and Accession: Key Points and Common Errors

ICP filing is not a one-time task. Changing service providers, updating information, or decommissioning sites each require specific actions. Confusing these types can lead to two consequences: either the filing does not match reality, or the website gets blocked.

This article explains the differences and key operational points for the three types. Specific processes and timeframes are subject to requirements from competent authorities and access providers.

Differences Between the Three Operations

Type When Required Description
Accession (Add Access) When changing server service providers Link existing ICP filing to a new access provider
Modification When entity or website information changes E.g., company name change, responsible person change, domain change
Cancellation When the site is no longer in use Proactively cancel the ICP filing

1. Accession (Changing Service Providers)

This is the most commonly overlooked type. Many believe “ICP filing follows the domain, so any provider is fine” — in reality, the filing is bound to the access provider. You must process accession when changing providers.

Key Operational Points

  1. Submit the accession application with the new access provider first, do not switch DNS resolution beforehand
  2. Before accession is complete, keep the old server active
  3. Only switch DNS resolution after accession is approved
# Confirm resolution target before switching
dig +short example.com A

# Confirm accessibility after switching
curl -I https://example.com/

What happens if the order is wrong: If you switch DNS before processing accession, the website may be blocked during the interim period due to mismatched filing information.

Common Errors

  • Moving servers without processing accession: The website gets blocked, and the cause is often hard to identify
  • Shutting down the old server before accession is complete: Leaves no fallback option
  • Assuming the filing will follow automatically: Requires proactive action

2. Modification (Information Changes)

Modification Scenario Precautions
Company Name Change Update domain real-name registration first, then apply for ICP modification
Responsible Person / Contact Info Change Update promptly to avoid contact issues
Domain Change New domains require new ICP filing
Website Name Change Must match actual content
Server IP Change Usually updated via the access provider

The sequence for company name changes is the most error-prone: After changing your business license, the domain’s real-name registration info does not sync automatically. You must update the real-name info with the registrar first, confirm it takes effect, and then submit the ICP modification. Otherwise, it will be rejected due to “entity inconsistency.”

# Verify domain real-name info (based on registrar backend)
whois example.com | grep -iE 'registrant|organization'

3. Cancellation (No Longer in Use)

When a site is no longer used, it is recommended to proactively cancel the ICP filing rather than leaving it inactive.

Why Cancellation is Recommended

  • If the domain expires and is registered by someone else, your entity remains linked to the filing, potentially creating liability associations
  • Long-term failure to update information is itself a risk
  • Reusing the same domain later requires handling historical records

Key Operational Points

  1. Confirm the site is indeed no longer in use (restarting operations after cancellation requires going through the full process again)
  2. Submit cancellation via the original access provider
  3. Keep proof of cancellation results
# Confirm domain resolution status before cancellation
dig +short example.com A
# If still pointing to the server, handle resolution first

Checklist

Scenario Action Required
Changed cloud service provider Accession (not Modification)
Company renamed Update domain real-name first, then Modify
Changed responsible person Modify
Site discontinued Cancellation
Changed domain New domain requires new ICP filing
Only changed server IP (same provider) Usually updated by access provider; just confirm

Decision Tree

Which operation is needed?
├─ Did you change service providers?
│  └─ Yes → Accession (Process accession first, then switch DNS, keep old environment)
├─ Did entity or website info change?
│  ├─ Company name → Update domain real-name first, then Modify
│  ├─ Responsible person/contact → Modify
│  └─ Changed domain → New domain requires new ICP filing
└─ Site no longer in use
   └─ Cancellation (Keep proof)

General Operation Sequence
├─ Process paperwork first, then switch DNS
└─ Keep old environment until new procedures are complete

Scenario Analysis: Site Unavailable Mid-Transition When Changing Providers

Symptom: A site changed service providers, but due to incorrect operation sequence, it became completely inaccessible for a period.

  1. Clarify the applicable conditions for each operation → Entity and domain remained unchanged, only the provider changed. This falls under “Accession”; “Modification” applies when info changes. This case was the former, but handled as the latter.
  2. Identify where unavailability occurred → Old provider resources were released, while the new provider’s accession process was not yet approved. Neither side could provide service.
  3. Understand why recovery was slow → During incomplete procedural states, recovery speed is much slower than ordinary faults.
  4. Clarify the correct sequence → Complete accession with the new provider and get approval first, confirm DNS points to the new service and is accessible, then release old resources.
  5. Run old and new environments in parallel for a period → The overlap period is the safest insurance, costing far less than downtime losses.
  6. Standardize pre-operation checks → Domain real-name status, certificate validity, and whether other processes are ongoing.
# Compare resolution targets before and after operation
dig +short example.com A
dig +short example.com NS

# Confirm accessibility on both sides
curl -sS -o /dev/null -w '%{http_code}n' https://example.com/

# First confirm domain real-name status matches current provider
# This step is confirmed in the console; CLI cannot check this

# Before submission, check for ongoing processes (simultaneous submissions conflict)

Root Cause: Operation sequence reversed — old resources released first, new process not completed. During the gap, neither party could provide service.

Two Key Takeaways:

  • The fixed sequence for changing providers is: Pass accession at new provider → Switch DNS and verify → Then release old resources. Reversing this creates a “no one manages it” gap.
  • The cost of running old and new environments in parallel is far lower than downtime losses. In such operations, the overlap period is the most cost-effective insurance; do not cancel early to save on a few servers.

Comparison of Prerequisites and Impacts for the Three Operations

Operation When Required Prerequisites Impact During Process
Accession Changing providers, but domain and entity remain unchanged New provider provides accession conditions Typically no impact on accessibility
Modification Changes in entity info, responsible person, or domain Complete and valid documentation Must remain verifiable during review
Cancellation Domain no longer used or entity no longer exists Confirm no pending matters Domain cannot be accessed under this entity after cancellation

Among the three operations, “Accession” and “Modification” are most frequently confused. The judgment method is simple: check whether the entity and domain have changed — if unchanged but provider changed, it is Accession; if any item changed, it is Modification. Submitting the wrong type directly leads to rejection, causing days of back-and-forth.

Four Mandatory Pre-Operation Checks

  1. Domain Real-Name Status: Is it successful? Does the real-name entity match the ICP filing entity?
  2. Certificate Validity: Expired certificates cause total failure.
  3. Current Filing Info: Record existing filing number and info as a baseline before modification.
  4. Pending Submissions: Multiple concurrent review processes conflict with each other.

The 4th item is easily overlooked. Submitting again while already under review usually fails or overwrites the previous submission, and interfaces sometimes do not explicitly prompt this; checking for ongoing reviews before submission saves a round trip.

Sequence When Changing Providers

  1. Complete accession at the new provider first, wait for approval.
  2. Confirm DNS resolution points to the new provider and access is normal.
  3. Then release old provider resources; do not cancel early.

Reversing the sequence (canceling old first, old stopped, new not yet approved) directly causes site unavailability. Because the filing is in a modified state, recovery is much slower than ordinary faults. Running old and new environments in parallel for a period is the safest insurance for such operations.

Timeline and Common Delay Causes

Stage Typical Duration Common Delays
Document Preparation Depends internally Expired certificates, unclear scans
Submission & Initial Review Several working days Inconsistency between filled info and documents
Review Several working days to longer Need supplementary explanations, back-and-forth
Result Confirmation Instant Failing to check notifications promptly, missing supplement deadlines

Delays mostly occur during document preparation and supplementary explanation stages, not the review itself. That is, cycle length largely depends on how carefully info is verified before submission, and how quickly responses are made to supplement notices — both of which are controllable.

Three Ways to Shorten Cycle Time

  1. Verify item-by-item against checklist before submission: Certificate validity, real-name status, exact name matching; get it right the first time.
  2. Set notification reminders: Review results and supplement notices have time limits; missing the supplement deadline means restarting the entire process.
  3. Provide all supplementary materials at once: When receiving a supplement notice, attach all potentially relevant materials together to avoid multiple rounds on the same issue.

The 3rd point aligns with ICP rejection logic: Providing everything possible at once is much faster than providing bits at a time. Back-and-forth in the review process is the most expensive cost; each extra round adds several days.

8 Common Pitfalls

  1. Changing providers without processing accession: The most frequent omission.
  2. Switching DNS before processing paperwork: Causes interruption.
  3. Stopping old environment before paperwork is complete: No fallback.
  4. Applying for ICP modification before updating real-name for company name change: Will be rejected; sequence should be reversed.
  5. Not canceling when site is discontinued: Liability association remains if domain is registered by others.
  6. Thinking changing domain just requires a record update: Requires new ICP filing.
  7. Not verifying info after modification: Multiple info fields must remain consistent.
  8. Not keeping operation proofs: Impossible to trace later.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are from real buyer reviews and consultations for similar O&M services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (providers include our store and peers, provided for reference only, not fictional tickets from this site):

10***85 2024-08-02 5.0 Secure & Reliable | Skilled Tech | Affordable Price Had ICP filing issues, helped me update them 10***13 2024-07-25 5.0 On-time Delivery | Skilled Tech | Timely Reply Fast and useful 10***09 2022-06-22 5.0 Affordable Price | Skilled Tech | On-time Delivery ICP rectification, useful service

10***51 2023-10-24 5.0 Skilled Tech | Complete After-sales | Affordable Price Tried several website migration services, this one is the most reliable.

10***47 2025-11-14 5.0 On-time Delivery | Secure & Reliable | Comprehensive Features (User did not fill comment content) 10***44 2022-09-16 5.0 Comprehensive Features | Affordable Price | Skilled Tech ICP rectification, easy to use 10***44 2022-09-16 5.0 Skilled Tech | Timely Reply | Affordable Price ICP rectification, useful service 10***67 2022-08-01 5.0 Patient & Professional | Affordable Price | On-time Delivery Easy to use and affordable 10***54 2022-07-15 5.0 Comprehensive Features | Affordable Price | Secure & Reliable Easy to use

FREE CHECKUP

Free server checkup

We will send a problem checklist and remediation advice within one business day — no obligation to engage.

135 410 16684
Weekdays Mon – Fri 10:00 – 22:00 (UTC+8) · 7×24 emergency response
Call now
CONTACT

Contact Us

How can we help?

* Required