Custom website development: the client says the company has a server room and old servers—can the official site just go there? IT says it saves trouble; we're worried about ICP filing and on-call support. Who should we listen to?

Let’s make the conclusion clear first: an official website can be placed on old servers in the company server room, but whether it can be placed there and whether problems will arise depends on four things—whether there is a qualified ICP filing access provider, whether there is a static public IP and sufficient outbound bandwidth, who is on call when something goes wrong, and how data is recovered if lost. Based on 2026 project delivery experience, for an enterprise official website aimed at lead generation, hosting on compliant cloud servers is usually less troublesome; old server-room machines are better suited to intranet systems, display pages with very low traffic, or scenarios where data truly cannot leave the intranet.

Moving an official website into the company server room actually touches five layers

Many clients think this is just “copy the website files to that machine in the server room and change the IP,” but the real trouble rarely comes from the code. As long as any one of these layers—server-room egress, public address, ICP filing access, certificates, and backups—is not aligned, go-live will get stuck that day, and often no one can clearly say where it is stuck.

It is advisable to check the five layers below in order, because if an earlier layer does not hold, doing the later ones well is meaningless. The compliance layer in particular is not a technical issue but a precondition for providing public services.

• Compliance layer: If the server is in mainland China and the domain provides public website access, ICP filing is usually required, and the filing must be under a qualified access provider; a self-built server room generally does not have this status.
• Network layer: The server room needs a static public IP and stable upstream bandwidth; office broadband often uses a dynamic address, which may change after a device restart.
• Security layer: Once an official website is exposed to the public internet, it will be scanned. Whether the server room has basic protection policies, access logs, and an owner for patches determines how quickly incidents are handled.
• Data layer: Whether backups are offsite and whether they can be restored to a specific day—if this is not solved, everything else is empty talk.
• On-call layer: The machine may be in the client’s building, but who handles restarts, full disks, and expired certificates in the middle of the night is another matter.

The ICP filing access threshold is still hard to bypass in 2026

As long as a site is hosted in a server room in mainland China and provides public access, the domain usually needs ICP filing first, and the filing is submitted under an access provider. Most enterprise self-built server rooms do not have the corresponding qualification and cannot act as the access provider. That is why a common practice is to put the ICP filing under a cloud provider and then point DNS to the server room—but this combination of “filing in one place, DNS in another” tends to cause problems during verification or spot checks.

ICP filing review typically takes 2 to 4 weeks (experience range), not counting time to supplement materials and resubmit after rejection. The reverse pitfall is more expensive: putting the site into the server room first and then applying for ICP filing; after egress is restricted, switching temporarily to the cloud means redeploying pages and reissuing certificates. The schedule typically increases by three to seven days (experience range), and during that period advertising and inquiries are cut off.

Five-question checklist: can this server room support an official website?

Rather than arguing “server room versus cloud,” break the question into five questions that the client’s IT team can answer face to face. The one they cannot answer, or answer only with “it should be fine,” is usually where rework happens later in the project. This checklist does not require jargon, and the client can use it to ask questions themselves.

1. How much outbound upstream bandwidth is there, and is it dedicated? A display-type official website typically sees daily concurrency in the single digits to dozens, but when bandwidth is taken up by office file transfers, the first screen will noticeably slow down.
2. Is there a static public IP, and can ports 80 and 443 be opened? If the address is not static, DNS has to be changed repeatedly, and certificate validation and share cards will also go wrong.
3. Who manages security and logs? The pass line is being able to pull access logs, having basic protection policies, and having a clear owner for patches.
4. How often are backups made, where are they stored, and how are they restored? The pass line is being able to explain the specific steps to “restore to a certain day last week,” not just answering “there are backups.”
5. Who is on call during failures, and how long does it take to arrive onsite? Remote handling and entering the server room are two different things; same-city and different-city make a big difference.

Cloud servers vs. self-built server rooms: compare delivery on these dimensions

Do not stop at whether it is expensive; cost is only one line item. What really creates the gap is bandwidth elasticity, security protection, and labor input. These are invisible on a quotation but will appear one after another in the first month after go-live.

• Compliant access: Cloud providers can usually act directly as the ICP filing access provider; most self-built server rooms need to find another access channel, making the process longer.
• Go-live cycle: On the cloud, provisioning a machine and installing the environment typically takes one to three days to run staging; in a server room, coordinating the network, opening ports, and going through internal approvals typically takes one to three weeks.
• Annual cost (experience range): For a small official website, cloud server plus bandwidth typically falls in the range of one to two thousand to five to six thousand RMB per year; on the server-room side, electricity, dedicated line or bandwidth, and backup disks typically total several thousand RMB per year, excluding operations labor.
• Elasticity: When traffic rises during advertising periods, cloud resources can be temporarily upgraded; a server room is limited by egress bandwidth and existing hardware.
• Incident response: The cloud has tickets and monitoring alert chains; a server room depends on the client IT team’s response habits and whether they are on duty.
• Data control: A server room is more “visible” at the physical level, but by the same logic, if a disk fails or data is deleted by mistake, the responsibility is entirely on the client’s side.

At delivery: when the client insists on old servers, how we hold risks down

One project in 2026 was like this: the budget was tight, the client’s IT person was part-time, and the old machine was still running internal OA and could not be stopped. Our approach was to first spin up a low-spec cloud server for staging and ICP filing access, use two sets of DNS records for switching the formal site, run a test domain for a week before switching to the formal domain; at the same time, we set backups to be offsite daily with 30-day retention, and walked the client’s IT person through a recovery drill.

The cost was real: go-live was about one week later than planned. By the typical range for such projects, a one-week delay is a relatively light cost; in the middle, the go-live window was changed once again due to server-room port approval, and the client’s IT person needed to spend an extra two hours coordinating. What we got in return was that after the switch, there were no repeated issues such as “content changes not taking effect” or “certificate expired.” By enterprise project delivery habits, most rework in such projects is not caused by wrong code but by assuming everything on the server-room side had been configured.

Applicable scenarios and boundaries

Not every official website is worth moving to the cloud, and not every server room is unusable; boundaries matter more than conclusions. The key judgment is: does this site need to be stably open to strangers on the public internet?

• Suitable for the server room: Intranet systems, content visible only after dealers or employees log in; display pages with single-digit daily visitors where someone already maintains the machine; scenarios where industry or group requirements state that data must not leave the intranet and outbound access requires approval.
• Not suitable for the server room: Public official websites aimed at lead generation, advertising, and search indexing; projects where the company has no operations staff at all; stages that require fast go-live or frequent revisions.

One sentence can serve as the test: If the official website needs to acquire leads publicly and be indexed by search engines, prioritize compliant cloud servers; only when data cannot leave the intranet and someone is truly on call is an old server in the server room a reasonable option.

Several pitfalls that are easily underestimated

What really causes headaches with server-room solutions is often not whether the site can open on day one, but the operations details three months later. During delivery acceptance, it is best to ask these one by one; only someone who can give specific operating steps passes.

• Manual certificate renewal: Certificates on the machine rely on someone remembering to renew them; if forgotten, the whole site shows as insecure, and clients will notice first.
• Older system versions: Old machines cannot install new components, so later feature additions have to take detours, and modification costs become higher.
• Office and official website competing for bandwidth: When colleagues transfer large files during the day, visitors experience slowness, and the problem is hard to reproduce.
• Single machine without redundancy: One disk problem stops the whole site, and recovery time depends on how detailed the backups are.

FAQ

If the official website is placed on a server in the company server room, is ICP filing still required?

As long as the server is in mainland China and the domain provides public website access, ICP filing is usually required, and the filing must be under a qualified access provider; a self-built server room generally does not have this status.

The server room has no static public IP. Can dynamic DNS make do?

For intranet or temporary demos, it can; for a public official website, it is not recommended: frequent address changes affect certificate validation, share cards, and search crawling, and add another layer of interference when troubleshooting.

The old server has low specs. Is it enough for a display-type official website?

A display-type official website has low processor requirements; the bottleneck is usually egress bandwidth and image size. Look at daily concurrency and asset size first, then specs; typical entry-level configurations can support small traffic (experience range).

The client says data should not be placed on the public cloud. Is there a compromise?

A common compromise is to put the official website on the cloud while keeping business data on the intranet, with one-way synchronization through APIs; public access is stable, and core data does not have to be moved out.

Before starting, find someone who can sign off on each of the four items: ICP filing access, static IP, backup and recovery, and on-call owner. If any one of the four has no one responsible, first put the official website on compliant cloud servers and keep the old server-room machine for intranet systems. The cycles and costs in this article are experience ranges; actual figures are subject to provider quotations and the client’s server-room conditions, and matters involving approval processes are subject to the client’s internal policies.