A corporate website used by overseas visitors needed management after it was built. Starting with the website build and cloud migration for Company S, a stone manufacturer, we connected content delivery, web security, and continuous operations.
A corporate website is not a deliverable used only on the day it goes public. It has to keep explaining the products and the company as time passes, and deliver the information people need when they visit from other countries.
Yet the end of a build project and the start of operations are often separated. The screens are finished, but who manages the server, where to look when overseas access is slow, and who responds when abnormal requests increase remain separate questions.
Company S, a stone manufacturer with many overseas visitors, needed both a website renewal and a migration of its existing hosting environment. IXC has continued the build and operations since 2020, handling these questions within the same scope.
Changing the design and the hosting separately was not enough
Company S started from slow overseas responses and rising traffic to the origin server. Abnormal requests had to be considered alongside legitimate use.
Treating this simply as choosing a bigger server misses something. Which requests should reach the origin server, where frequently used content should be served from, and which visitors must never be blocked all have to be decided together.
To understand why the website build and the cloud migration went ahead together, the screens and the underlying environment have to be seen as one system. The page a visitor meets is the result of design, and at the same time the result of content delivery and server operations.
Moving the server needed an order of transition
The existing hosting environment was migrated to the cloud. We set the order of transition, ran a rehearsal, and carried out the cutover within the work window.
What matters in a migration is not only that the files have landed in the new environment. The functions and content the old site provided have to be confirmed to continue in the new one. The operating owner and the inspection standards after the work are needed as well.
A transition plan is the means of turning these confirmations into a work sequence. Only when what to prepare first and when to switch the live service path are set out does the migration itself become explainable work.
After the build and migration were complete, monitoring, changes and patches, incident response, and security inspection continued as the scope of operations.
We divided overseas content delivery from the role of the origin server
A CDN was applied to the overseas response problem. Static assets are served from distributed delivery points, and cache policy was adjusted by reviewing responses by region. Traffic reaching the origin server fell by 1 TB a month.
A CDN need not be seen simply as a speed option attached in front of a site. It is also a way of dividing roles so that the origin server does not serve frequently requested content directly every time.
Storing all content under the same policy is not the goal, however. Information that is updated and assets that can be cached have to be told apart. Fast delivery and serving the correct content are conditions that must be met together.
In this case too, the server migration and the content delivery path were not treated as separate choices, but as part of running the website.
Security was about protecting legitimate visitors, not the volume blocked
A web application firewall was applied to abnormal requests, and the rules were adjusted by reviewing block records. Because the website needed to serve overseas users, not blocking legitimate visits had to be considered as well.
A large number of blocked requests alone is no proof of good security operations. If real customers were kept out too, the website has failed in its role. Conversely, allowing every request can leave the origin environment carrying unnecessary load.
So this task is not a matter of deciding what to allow and block once and being done. It is a matter of checking the nature of requests and the results of blocking, and adjusting to the operating conditions.
The layer that delivers content quickly and the layer that filters hostile requests play different roles. Handling the CDN and the web application firewall together is distinct from trying to solve every problem with a single technology.
Long-term operations need a standard outside any one person's memory
Over time the site changes and the people in charge may change too. If the reasons behind earlier work have to be traced from scratch each time, maintenance becomes progressively harder.
In operating Company S, inspection and response procedures were written into operating documents, and the service status was reviewed regularly. It is a structure that handles the website, the cloud environment, content delivery, and security rules together.
Operating documents cannot replace every judgment. But they have value in sharing the standards for recurring work and in conveying what to check even when the person in charge changes.
In this project, long-term operations mean more than the length of a contract. It was a matter of carrying the choices made at build time into the inspections and changes that followed.
A corporate website is completed after it goes public as well
This case connects a website build, cloud migration, CDN adoption, and web application firewall operations. More important than adopting any one of them is a structure that keeps handling each element according to the actual conditions of website use.
When evaluating a corporate website, there are aspects that the first screen and the initial build cost do not reveal. How overseas users connect, who applies the next change, and what the response to a problem is based on are also part of a website's quality.
The Company S case is a project that went from handing over a website as a deliverable to managing it as a corporate asset that stays in use.