INCL Ishikawa Computer Center Co.,LTD.: what the network, cloud transition and local staff actually prove

Summary

• The BTW directory entry gives the assigned identity as INCL Ishikawa Computer Center Co.,LTD., but the operating boundary becomes clearer on the company's own sites. Ishikawa Computer Center Co., Ltd., usually shortened to ICC, is the company. INCL is the commercial internet provider ICC says it launched in 1995. That distinction matters because an INCL access contract, an ICC cloud contract and a place in ICC's Hakusan data centre may involve the same group but are not the same service or control surface.
• The network evidence is unusually tangible for a regional provider. APNIC RDAP records active Japanese AS18121 as INCL and names Ishikawa Computer Center. On July 15, 2026, RIPEstat showed six visible IPv4 prefixes, one IPv6 prefix, 19 observed neighbours and near-complete visibility among its route collectors. PeeringDB displayed operational connections at five Japanese exchange points. These are strong signs of a functioning public network, but they do not identify which route, upstream or failure domain carries any particular cloud tenant.
• The service evidence also goes beyond a generic cloud label. ICC describes a Hakusan facility, housing, managed infrastructure, remote backup, monitoring, network services and technical support. Its VMware-based Vase IaaS lets customers configure virtual machines and networks through vCloud Director, but the same page says Vase will end on March 31, 2027 after Broadcom's acquisition of VMware, with a new virtual platform starting in June 2026. The critical assurance question is therefore migration: how customer state, controls, addresses, backups and recovery obligations move, and who has authority when automation does not complete cleanly.
• Locality and support have credible anchors but still need contract-level proof. ICC publishes physical controls, 24/365 operation for data-centre circuits, technical consulting and a public maintenance feed. A Hakusan City document describes sensitive electronic media held in an Ishikawa Computer Center facility under gate, biometric and server-access controls. Those facts make Hakusan more than a marketing location. They do not prove that every workload, replica, log, administrator or replacement platform stays in the same place. A buyer should treat ICC as a demonstrable regional operator and then verify the exact data path, support chain and tested exit for the ordered service.

One name contains three operating identities

The most useful way to read INCL Ishikawa Computer Center Co.,LTD. is not as a single brand printed on every layer. It is as a compact description of three related operating identities. There is the company, Ishikawa Computer Center Co., Ltd., or ICC. There is INCL, the internet service provider. And there is a wider ICC technology business spanning software, systems integration, outsourcing, data-centre services and cloud products. They reinforce one another, but they should not be substituted for one another when the question is who controls a workload.

The ICC company outline establishes the corporate anchor. It gives the Japanese company name, a Kanazawa head office, capital of 222 million yen, an establishment date of October 5, 1972 and 463 employees as of July 2026. It lists locations in Kanazawa, Hakusan, Tokyo, Nagoya, Osaka, Toyama and Fukui. The corporate history says the business began as Ishikawa Electronic Computing Center, took its present name in 1987, registered as a telecommunications operator in 1988, launched the commercial internet service incl in 1995 and opened the Hakusan Center in 2012. That sequence matters. Computing services came first, telecoms followed, the ISP brand arrived later, and the dedicated facility became another operating layer.

The INCL site makes the brand boundary explicit: incl is an internet provider operated by ICC. It offers routes for individual and corporate customers, connection and email settings, applications, account changes, cancellation, support, maintenance notices and the internet-service contract. This is not a dormant alias attached to an autonomous-system record. It is a customer-facing service with ordinary lifecycle tasks, including the less glamorous but decisive act of leaving.

ICC's wider business is different again. Its official material includes application development for government bodies, medical institutions and private companies; system design and hardware; outsourced processing; a data centre; security services; cloud; business-process outsourcing; and the commercial ISP. Ishikawa Prefecture's company page independently describes the same broad mix: business applications, hardware, internet connectivity, provider services, data centre and cloud, information processing and security. The agreement between company and prefectural descriptions helps with attribution. It does not mean every product inherits every capability.

That last distinction is the first diligence test. If a customer orders internet access from INCL, the relevant system may be an access circuit, authentication, DNS and email. If it orders Vase, the relevant system includes a virtualisation control plane, compute, storage and network resources. If it rents rack space, it may own the servers while ICC supplies power, physical security, remote hands and connectivity. If it buys an application for a municipality or hospital, software support and domain expertise may matter more than the public ASN.

A familiar company name can sit over all four contracts, yet the failure owner and recovery method will differ in each.

The name therefore provides a credible starting point, not a universal answer. ICC is the party whose current legal details, signatory authority and service obligations should appear in the paperwork. INCL identifies a specific ISP heritage and network surface. The product name identifies the technical boundary. Good operating assurance begins when those labels are kept distinct and then connected with explicit responsibility.

The corporate footprint is substantial, but scale is not the verdict

Thin infrastructure identities often leave a prospective customer asking whether a company can be found at all. That is not the problem here. ICC publishes an address, telephone number, current leadership, office footprint, group companies, business lines, a half-century chronology and a current staff count. The prefectural page provides an outside institutional reference. The company and product sites have current 2026 notices. The public set supports a straightforward conclusion that ICC is an active operating company with a real regional base.

The chronology adds more than age. ICC says it obtained ISO 9001 certification in 2001, information-security certification in 2004, ISO 14001 in 2005, a privacy mark in 2010, a data-centre safety certificate in 2013 and ISO/IEC 27017 for cloud security in 2021. It lists technical qualifications across security, networking, databases, project management, cloud, data-centre operations and IT service management. Those entries describe an organisation that has had to formalise quality, security and operational disciplines across several generations of technology.

Still, neither age nor a row of certification names should settle a procurement decision. A certification has a defined legal holder, site, service scope, version, audit period and set of exclusions. A qualification list does not reveal how many qualified staff are on a particular shift or whether they are authorised to change the system at three in the morning. A 463-person workforce can support considerable breadth, but it can also be divided among public-sector applications, healthcare products, enterprise systems, sales, administration, data-centre work and the ISP. The denominator for a customer is not total headcount.

It is the people and controls attached to the ordered service.

Scale should therefore be used to ask better questions. A buyer can ask which ICC unit owns the contract, which team designs the service, which team watches it, which team can restore it and which group company or external supplier participates. It can ask whether the certificate on the website covers the Hakusan facility, the cloud platform, the support process or all three. It can ask for a current certificate and its scope rather than assuming that a logo covers every system sold by the company.

This is not scepticism for its own sake. The public record makes ICC more inspectable than a provider whose only trace is an address block. Inspection is valuable precisely because it can connect organisational scale to a real outcome. When ICC says it can provide design, migration, network, backup, monitoring and post-deployment advice, a customer can require those responsibilities to appear in a service design. When the company says it has security and cloud certifications, the buyer can map the relevant controls to its data and administration model. A substantial footprint creates the possibility of assurance.

The contract and operating test make that possibility specific.

AS18121 is a real operating signal, not a decorative number

The network record is the clearest technical reason not to dismiss INCL as a branding remnant. APNIC's RDAP response for AS18121 marks the autonomous system active in Japan, names it INCL and describes Ishikawa Computer Center Co.,LTD. The last-change event in that response is old, dated August 27, 2005, so RDAP alone is not a measure of current traffic. Current routing observations fill that gap.

On July 15, 2026, the RIPEstat overview said AS18121 was announced and retained the INCL and Ishikawa Computer Center holder label. Its announced-prefix view showed seven origin prefixes during the July 1-15 observation interval: six IPv4 entries and one IPv6 entry. The routing-status response showed IPv4 visibility at 325 of 326 responding route collectors and IPv6 visibility at 321 of 322. It reported 19 observed neighbours. Whatever the mix of retail access, customer services and data-centre traffic behind those announcements, this is a currently visible network, not merely a historical registration.

PeeringDB's AS18121 page supplies another view. It classifies the network as Cable/DSL/ISP, gives INCL as the alias, describes traffic as heavy inbound and scope as Asia Pacific, and declares 30 IPv4 prefixes and five IPv6 prefixes. It also displays five operational exchange connections: JPIX in Tokyo and Osaka, BBIX in Tokyo and Osaka, and JPNAP in Tokyo. Four rows show 20 Gbps ports; the JPNAP Tokyo row shows 100 Gbps. IPv4 and IPv6 interface addresses appear on each.

The prefix figures should not be collapsed. PeeringDB's 30 and five are operator-declared network fields. RIPEstat's six and one are prefixes observed as originated during a particular interval, with one more-specific IPv4 entry appearing alongside its covering range. They are different measures, maintained through different processes. One cannot subtract them to infer missing routes or add them to produce capacity. Their useful agreement is directional: both describe a dual-stack network with materially more than a token route.

The exchange records are similarly valuable but bounded. They establish public interconnection points and displayed port capacities. They do not say how much traffic traversed each port, which peers exchanged it, whether every path was simultaneously diverse, or whether a cloud tenant could survive the loss of a particular carrier, conduit or city. PeeringDB shows no public facility association for network 2713 and no public contact visible without authentication. Those empty fields do not negate the Hakusan facility or the support routes on ICC's sites. They simply mean PeeringDB cannot be used to make that join.

The right conclusion is stronger and narrower than "the company has an ASN." ICC operates a widely visible Japanese autonomous system with several public exchange connections. That is meaningful network-resource evidence. The remaining task is to show how the exact service reaches that network, which paths are independent, which party operates the edge and what happens when one of those dependencies fails.

The route to Tokyo is not the route to every workload

ICC's network-service page says the Hakusan Center has 100 Gbps connectivity toward Tokyo and 50 Gbps toward Osaka, with major internet exchanges and multiple upstream connections. It offers bandwidth-guaranteed internet service to customer racks, wide-area Ethernet, dedicated lines, FLET'S connectivity, address and domain administration, DNS, certificates, firewalls and internal cabling. It also says specialists operate IDC lines around the clock throughout the year.

Those claims fit the public exchange picture, particularly the presence in both Tokyo and Osaka. They provide a plausible operating narrative: a regional facility connects into major Japanese interconnection markets while ICC uses its own ISP capability to supply customer connectivity. But "fits" is not the same as proving a complete topology. The public pages do not map the 100 Gbps and 50 Gbps statements to the PeeringDB ports, name every upstream, show physical conduit diversity or identify which link carries a particular product.

That uncertainty matters because customers experience networks through failure domains, not headline bandwidth. Two circuits can terminate on separate routers but share a building entrance. Two upstreams can converge on the same metropolitan path. A cloud management console can remain reachable while storage traffic is impaired. A backup job can complete over an internet path that is too slow for a full restore. A dual-stack network can still have different resilience and filtering behaviour for IPv4 and IPv6. Capacity is an ingredient; path independence and recovery are the service.

A buyer should ask ICC for a service-specific path map at the right level of detail. The document need not expose sensitive router configurations. It should identify the customer handoff, access medium, ICC edge, upstream or exchange path, primary and alternate cities, addressing responsibility, denial-of-service protection, DNS dependencies and monitoring points. It should say whether advertised redundancy survives maintenance and how route changes are authorised and reviewed.

The same discipline applies to autonomous-system evidence. If a tenant receives an address from ICC, the contract should say whether it is portable, what happens during migration and how long routing and DNS changes take. If the tenant uses its own addresses, the provider should explain route validation and withdrawal. If the service uses private connectivity, AS18121 may be only one part of the path. If ICC resells an external cloud connection, the external platform's network and account controls enter the chain.

AS18121 makes these questions easier to answer because there is a real operator and visible interconnection surface to start from. It does not make them unnecessary. Network assurance is not the act of finding a number in a registry. It is the act of joining that number, the physical path and the customer's recovery requirement without leaving an unowned gap.

Hakusan gives locality a physical anchor

Cloud locality is often inferred from a region name on an order form. ICC offers more concrete material. Its data-centre overview presents building, equipment and staff as one service and explicitly positions the facility for regional backup and disaster recovery. The facility page places the centre within driving distance of Kanazawa Station and Komatsu Airport and describes a base-isolated structure, direct and induced lightning protection, dual utility feeds, up to 8 kVA per rack, N+1 gas-turbine generators with a claimed 72-hour run without refuelling, camera coverage and nitrogen fire suppression.

These are inspectable physical propositions. They describe where equipment can sit, how power continuity is approached and how access is observed. They are more useful than an unqualified claim that data is "in Japan" because they let a customer ask about a named site, its equipment, its staffing and the assumptions behind continuity. They also create testable details: generator fuel strategy, maintenance history, access records, power-path design and the rack-level arrangement can be examined during diligence.

A Hakusan City personal-information assessment provides a bounded outside example. The city document says relevant electronic media were stored in an Ishikawa Computer Center data centre with security-gate access, that the room used a biometric electronic lock and that server access required an ID and password plus facial authentication. It also describes logical separation and encryption for a cloud service in the wider system. This is meaningful because a public authority identified ICC's facility in the context of sensitive information and named specific controls.

The example must not be stretched. It concerns the assessed municipal system, not every ICC customer. It does not prove that all clouds, backups, logs or support attachments use the same room, authentication path or data treatment. Nor does it establish the present configuration of a service that may have changed since the assessment. It demonstrates that ICC can be connected to a concrete workload and control description. A new customer still needs its own connection.

Data sovereignty also extends beyond the server room. Physical locality asks where compute and storage are installed. Administrative locality asks where people and service identities can access them. Control-plane locality asks where identity, orchestration, monitoring and ticket systems operate. Recovery locality asks where replicas and backups will be restored. Legal locality asks which entities and subprocessors can be compelled or contracted to act. A Hakusan rack answers only part of this set.

The practical buyer question is therefore not "Is ICC local?" ICC has a demonstrable Ishikawa base. The question is "Which parts of this service are local, under which normal and emergency conditions?" The answer should identify primary data, replicas, snapshots, logs, account metadata, support attachments, monitoring data and administrative access. It should explain what can leave Hakusan during troubleshooting or failover. A regional facility becomes sovereignty assurance when these flows are contractually bounded and operationally verified.

Vase turns platform dependency into a current operating test

The most revealing page in ICC's public set is not the company history or the data-centre specification. It is the page for Managed Cloud Vase. Vase is described as IaaS delivered from ICC's data centre. VMware vCloud Director supplies the control panel through which customers create virtual machines and networks. The page offers a flexible Self form and a simpler form with an installed operating system and internet connection. It describes hybrid links to customer premises or housed equipment, monthly fixed pricing, selectable compute, memory, storage and network resources, and claimed redundancy across hardware and communications paths.

Then the page states that the service will end on March 31, 2027 because of the impact of Broadcom's acquisition of VMware. It says a new virtual platform begins in June 2026. This is not a theoretical warning about software concentration. It is a live example of a regional cloud having to change its service when the economics or terms of a foundational vendor change.

The transition does not by itself imply service failure. It may produce a better platform, a clearer cost structure or less dependence on one supplier. ICC has given customers a public date and points to a successor. That is more useful than allowing a legacy service to drift without an exit. Yet the value of the notice depends on the migration mechanics behind it.

A virtual-machine migration is not just the movement of disk images. It includes network definitions, addresses, firewall policy, identity roles, snapshots, backup agents, monitoring, operating-system support, licences, automation, audit history and recovery procedures. A feature that appears equivalent at the console can behave differently during failure. Image formats can move while network semantics do not. A copied machine can boot while an application remains unable to find storage, DNS, secrets or a licensed dependency. The hard part is preserving the system's state and obligations, not reproducing the appearance of a server.

Customers therefore need a migration contract rather than a general successor-platform announcement. It should state who identifies dependencies, who performs conversion, what downtime is expected, what is tested before cutover and what rollback remains possible. It should identify changes to addresses, connectivity, operating-system support, backup retention, administrative roles, logging, monitoring and price. It should say how long the original environment remains available if acceptance fails and how old data is removed after success.

The transition is also a test of support authority. An automated migration tool may complete most workloads and fail on the unusual ones. The consequential questions are who recognises a partial move, who can alter the target configuration, who approves a rollback and who communicates with an underlying vendor. ICC's value as a regional operator is greatest in those exceptions, where local engineers can understand the customer's old system and make a decision. The customer should verify that this labour is included, scheduled and empowered.

Vase thus exposes the difference between infrastructure ownership and platform control. ICC can operate the facility, network and service organisation while still depending on a vendor's virtualisation stack. The 2027 end date shows that dependency reaching the product boundary. A credible replacement is not one that merely has new software. It is one that preserves customer outcomes, makes changed responsibilities explicit and leaves every workload with a tested route forward or out.

Automation is valuable until state becomes ambiguous

Vase's control panel illustrates the appeal of enterprise automation. A customer can allocate virtual machines, change resource assignments and configure networks without waiting for every manual action. ICC's monitoring products automate reachability and resource checks. Its wider business includes ERP, sales-force tools, municipal systems and medical applications that turn repeated administrative work into software. Automation is not a decorative topic here; it is part of how ICC converts a regional facility and support team into a service that can serve many customers.

The operating test is what happens between request and accepted outcome. When a user presses a power control, does the interface distinguish requested, running and verified states? If a network change only partly applies, does the system expose the inconsistency? If an operation times out, can it be retried without duplicating or corrupting resources? If a migration changes a machine but not its monitoring or backup policy, which system reports the gap? These are ordinary questions for any automated infrastructure, and they become sharper during a platform transition.

Good control-plane evidence has several layers. An identity record shows which human or service account initiated an action. An authorisation record shows why the account was allowed to do it. A change record captures the old state, intended new state and actual result. A health check shows whether the application outcome followed the infrastructure action. An exception route assigns a person with permission to diagnose and reverse the change. Retention and export rules keep this evidence available even when a tenant leaves.

ICC's public Vase page tells customers that access uses HTTPS, a customer-specific URL, an ID and a password. That is useful descriptive detail, but it is not a complete 2026 control model. A buyer should ask whether stronger authentication is available, how privileged ICC access is separated, how dormant accounts are removed, how service identities are governed and how logs can be exported. It should ask whether the replacement platform changes these controls. The answer matters especially for customers handling health, municipal or other sensitive information.

Automation also shifts labour rather than eliminating it. Customers no longer wait for a technician to create every machine, but someone must design templates, review capacity, maintain the platform, handle exceptions and reconcile billing. Monitoring reduces continuous manual checking, but someone must tune thresholds and respond. Migration tooling reduces repetitive conversion, but engineers must investigate the outliers. The economic comparison is therefore not software versus people. It is one arrangement of people, tools and exceptions versus another.

The right success measure follows that reality. Count accepted migrations, not started migrations. Measure recoverable machines, not copied disks. Track changes that required manual repair, time to restore a known-good state, identity exceptions and missed dependencies. For ongoing service, measure successful customer outcomes, restoration time and intervention effort. A control panel is valuable because it compresses ordinary work. Assurance comes from seeing what it does when the work stops being ordinary.

Backup evidence is not yet recovery evidence

ICC's BCP remote-backup service is another concrete operating surface. The company says customers can send data over the internet or VPN, use software compatible with the Amazon S3 API, begin with a relatively small allocation and protect retained files from overwrite, deletion errors or ransomware alteration for a set period. The basic description includes 100 GB of storage, with added capacity available. ICC also offers consulting and systems integration around the setup.

This is a recognisable product rather than an abstract claim of resilience. It defines transport options, an interface model, a storage unit and a retention control. It also acknowledges the labour problem that often undermines backup: small organisations may lack dedicated staff, remote offices may be missed and media handling may become burdensome. A local provider that can configure the path and help the customer test it can be more useful than a technically larger service left unattended.

But a successful backup job is only the opening condition for recovery. A customer must know whether the protected copy contains every dependency needed to restart, whether credentials survive a primary-site failure, whether enough bandwidth is available for restoration, whether retained data can be selected at the right point in time and whether the target environment is compatible. If Vase is being replaced, the question becomes particularly concrete: can a backup made for the old environment be restored into the new one, and has that path been exercised for the customer's operating system and application?

ICC's data-centre home page provides a useful sign of operational candour. Its public maintenance feed listed a restored access incident affecting the BCP backup management site on July 8, 2026, alongside planned facility and product maintenance notices. The notice does not establish that stored backup data was unavailable, and it cannot be used to calculate a general reliability rate. It does show that the management surface can have a distinct incident state and that ICC publishes at least some operating notices.

That distinction should shape a recovery exercise. If the management site is unavailable, can the customer still open a restoration request? Can ICC staff reach the protected data through another authorised path? How are emergency actions authenticated and recorded? If the primary customer identity system is down, what break-glass process remains? A backup service needs an operating route that survives the incident it is meant to address.

The strongest evidence would be a completed restore with measured results. Select a representative protected system, choose a recovery point, restore it into an isolated target and verify application integrity. Record the data gap, elapsed time, transfer bottleneck, manual steps, identity exceptions and the people who authorised release. Then repeat after a significant platform or network change. ICC's product description makes such a test plausible. Only the result tells a customer whether its own continuity objective can be met.

Monitoring defines a boundary, not an outcome

ICC's system-monitoring page is refreshingly specific about several checks. Reachability monitoring sends three ICMP echo requests and treats the absence of a response within two seconds for all three as a warning condition. Port monitoring uses the TCP three-way handshake. Service monitoring requests a specified URL, does not support pages requiring authentication and looks at response timing and status-code ranges. Resource monitoring checks CPU, memory and storage against customer-selected thresholds.

Those definitions are valuable because "monitored" is otherwise an almost empty word. The page lets a buyer see what is actually being observed and where the blind spots begin. ICMP reachability says a host responds to a network probe; it does not show that a business transaction works. An open port shows that a listener answered; it does not show that the application behind it can read its data. A public URL check cannot see an authenticated user journey. A CPU threshold may detect saturation but not silent corruption or a queue that is growing below the alert level.

The response process matters as much as the detection. The public page does not, by itself, establish which checks run at what interval for every service, who receives an alert, how duplicate alarms are grouped, when a customer is called or which remediation ICC may perform without approval. Those terms can vary appropriately by contract. They should still be explicit. Otherwise an alert can travel through several systems while no one owns restoration.

A customer should build monitoring from its operating objective backward. For an internet service, test name resolution, route reachability, authentication and a representative transfer. For an IaaS workload, add hypervisor state, storage, network policy and the application transaction. For backup, monitor job completion, retained-copy integrity and periodic restore. For a migration, compare source and target inventory and confirm that every machine still has its expected backup, monitoring and access policy after cutover.

This is also where network and software evidence meet. AS18121 can remain visible while a tenant application fails. The Hakusan facility can retain power while a control-plane dependency breaks. A virtual machine can be running while its user transaction is not. Each layer needs a signal, and someone needs the authority to decide which layer to repair first.

Monitoring is therefore not proof that the service is healthy. It is a designed observation system that reduces the time between failure and informed action. ICC publishes enough detail to let a customer begin that design. The remaining work is to connect the checks to service objectives, escalation and verified restoration rather than accepting a generic monitoring label.

Local support labour is part of the architecture

The phrase "computer center" can sound old-fashioned, but it points toward something modern cloud language often obscures: systems continue to depend on people in a place. ICC's service pages repeatedly join facilities and software to labour. Its data-centre overview says building, equipment and people act together. Its network page says specialists manage IDC lines 24 hours a day, 365 days a year. Its technical-support page describes consultation on migration, capacity, circuits, backup and monitoring, followed by optimisation, security advice and equipment guidance after deployment.

That service model can create a genuine regional advantage. A customer with a hybrid estate may need someone who understands the old on-premises machine, the circuit into Hakusan, the virtual target and the backup procedure. A support team close to both the facility and the application business can reduce the handoffs that occur when each layer belongs to a separate global supplier. ICC's history in public-sector and medical software may also provide domain context that a pure infrastructure vendor lacks.

None of this should be converted into an assumed response commitment. The reviewed public pages do not provide one general severity table, acknowledgement time, restoration target or customer-update interval covering all products. Twenty-four-hour operation of an IDC circuit does not necessarily mean every application consultant or migration specialist is continuously on shift. A support page and telephone number establish a front door. They do not show how quickly the door reaches a person authorised to restore a particular service.

The absence of a public PeeringDB contact adds a small but useful boundary. It means an unauthenticated reader cannot retrieve a network-operations or peering contact through that directory, although PeeringDB notes that some contacts are restricted to signed-in users. It does not mean ICC lacks network staff or customer support. The customer-facing sites have support and inquiry paths, and the network page describes continuous specialist operation. For assurance, the private contract should bridge these worlds with a named escalation matrix.

That matrix should identify first response, technical ownership, incident command, vendor escalation and executive communication for each severity. It should distinguish acknowledgement from active diagnosis and restoration. It should say who can make an emergency network, storage or identity change and what approval is required. For the Vase transition, it should name the team responsible for migration exceptions and the route for a failed acceptance test.

Customers can test the human chain before a crisis. Open a low-severity request, ask for a technical explanation, escalate it and verify that the history remains visible. Run a restore or controlled failover. Schedule a migration rehearsal and introduce a safe exception. Record the time lost at each handoff and whether the person who answered could act. This is not theatre. It measures a component of the architecture that no route collector or facility specification can see.

Public-sector and medical work raise the standard of proof

ICC's business-activities page describes municipal systems for resident information, welfare, payroll, documents, finance, schools, libraries and disaster management. It describes healthcare products for records, health checks, laboratory work and nutrition, as well as services for private companies. The company also offers LGWAN-ASP services through its data-centre catalogue. These are not ordinary brochure categories. They are settings in which availability, access, correctness and locality can affect public services or sensitive information.

The Hakusan City assessment shows how the proof standard changes. It does not merely say a cloud is secure. It identifies a storage location and controls for physical entry, room access and server access in the assessed arrangement. That is closer to the level at which public bodies make decisions: which information, in which system, held where, available to whom, protected by what control.

A historical Juniper Networks case study adds technical context. Published in 2017, it described ICC delivering IaaS and SaaS to municipal, medical and enterprise customers and using VMware NSX with Juniper QFX5100 equipment for the physical network beneath a virtualised cloud. The case study is useful corroboration that ICC had real cloud-engineering concerns, including underlay performance and vendor dependence. It is too old to describe the 2026 environment, especially when the current Vase page announces a platform change.

This combination of old and new evidence is instructive. The 2017 material shows how the VMware era was constructed. The 2026 product notice shows why that architecture now has to evolve. Public-sector and healthcare customers cannot treat the change as a routine refresh if it affects data placement, security controls, supported operating systems, audit evidence or continuity plans. Their acceptance criteria should follow the obligations of the workload, not the convenience of the migration tool.

For a municipal system, the customer may need to revalidate logical separation, administrator access, logging and domestic data handling. For a medical system, it may need to test record integrity, interface compatibility and downtime procedures. For both, backup retention and restoration should be demonstrated after the move. An application can function in a demo while its control evidence no longer matches the approved design.

ICC's breadth can help here because software, infrastructure and support expertise sit within the same wider organisation. It can also blur accountability if responsibilities are not written down. The customer should know whether the application team, cloud team, network team or an external supplier owns each risk. Higher-stakes work does not require a provider to promise perfection. It requires precise ownership, measurable controls and a recovery path that has been exercised.

A buyer should verify six joined chains

The public record is strong enough to support a practical diligence model. It is not necessary to restart from the vague question of whether ICC exists. The buyer can instead test six chains and insist that they meet at the proposed workload.

The first is corporate identity. The contract, invoice, privacy terms, support domain and authorised signatory should resolve to the correct ICC entity. INCL should be identified as a service or brand where relevant, not allowed to obscure the contracting party. Group companies and external suppliers should be named for the work they actually perform.

The second is product state. The order should name the current platform, service form, resources, operating-system support, included options, lifecycle dates and migration status. For Vase customers, it should state whether the workload remains on the old platform, has moved to the replacement or is scheduled to move. A generic cloud line item is not enough during a known transition.

The third is the network path. The service endpoint should connect to the appropriate ICC network, private circuit or external provider. Primary and alternate paths, addressing, DNS, route security, filtering and denial-of-service responsibilities should be clear. AS18121 and the public exchange footprint provide useful corroboration, but the service design must identify the path the customer actually uses.

The fourth is locality. The contract should locate primary compute, storage, replicas, backups, logs and administration. It should state what moves during support, recovery or migration and which subprocessors can receive it. Hakusan is a credible physical anchor, but locality becomes enforceable only when the data classes and exceptions are named.

The fifth is automation and recovery. The customer should receive role definitions, change records, audit export, monitoring scope, backup policy and a tested restoration procedure. Migration acceptance should verify the application and its controls, not just machine power state. Exceptions should have an owner and a rollback route.

The sixth is support labour. The escalation matrix should reach people with authority across application, platform, storage, network and facility layers. Hours, languages, severity, response, update and restoration objectives should match the consequence of failure. Supplier handoffs should remain ICC's managed responsibility where the contract says ICC operates the service.

These chains prevent individual facts from carrying too much weight. A company registration cannot prove application recovery. A route cannot prove data location. A data-centre specification cannot prove that a particular virtual machine is there. A certification cannot prove the scope of a customer's configuration. A support promise cannot prove that the responder can alter the underlying platform. Each fact is useful when it joins the next one.

The most useful tests are ordinary and repeatable

A provider with ICC's public footprint should be assessed through ordinary operating evidence, not an elaborate one-time spectacle. Start with account creation. Confirm the contracting identity, the service name, the roles granted, the administrative domain and the support route. Create a small non-sensitive workload and record how provisioning, addressing, DNS, monitoring and billing align.

Then introduce controlled change. Resize a resource, alter a network rule, rotate a credential and export the change history. Confirm that the old and new states are visible and that the service reports partial failure clearly. Ask support to explain an alert and verify that the person responding can reach the right technical owner.

Next test continuity. Protect representative data with the backup service, select a recovery point and restore it into an isolated environment. Measure transfer time and manual effort. Repeat using the target platform that will remain after Vase ends. If the application depends on a private link, identity provider, licence server or external storage, include those dependencies rather than restoring a machine that cannot perform useful work.

Test locality through records as well as observation. Match facility and system descriptions to the contract. Review access records, support-access locations, backup placement and subprocessor lists. Ask what changes during emergency support. If a public-sector or healthcare control depends on a specific location or authentication method, verify it after migration.

Finally, test exit. Export data, configuration, logs and evidence in usable formats. Withdraw routes or addresses where relevant, remove accounts, obtain deletion confirmation and preserve what the customer needs for audit. The INCL site visibly provides a cancellation path for internet customers; cloud and managed-service exits deserve the same operational clarity. A provider becomes easier to trust when leaving does not require the loss of state or bargaining power.

These tests are proportionate. A small website may need a modest version. A municipal, medical or operationally critical system needs a deeper one. The principle remains the same: the customer should observe the complete path from request to accepted outcome and from failure to recovery. ICC has enough visible infrastructure and staff to make that test concrete.

A fair conclusion is stronger than either trust or suspicion

INCL Ishikawa Computer Center Co.,LTD. is not a case where a technical-sounding name outruns every public fact. The company identity is clear. The INCL brand has a current ISP site and a history reaching back to 1995. AS18121 is active, dual-stack, visible and present at several Japanese exchanges. ICC describes a substantial Hakusan facility, network services, cloud, backup, monitoring and support. A public authority has identified the company's data centre in a sensitive-information assessment. These are meaningful operating signals.

Nor do those signals collapse into universal assurance. The assigned name combines company and brand. Route visibility does not identify a tenant path. A Hakusan facility does not locate every log, replica or administrator. Certification names do not reveal every scope. Twenty-four-hour network operation does not define every product's restoration target. Most importantly, a current cloud page says the VMware-based Vase service will end in March 2027 while a replacement begins. The service a customer relied on yesterday may not be the service it relies on tomorrow.

That transition is not a reason to reject ICC. It is the moment at which ICC's claimed strengths can be demonstrated. A provider with local engineers, its own facility, a live network and experience across applications and infrastructure should be able to trace each customer from old platform to new, preserve controls, test recovery and make exceptions accountable. The migration outcome will say more about operating quality than another general statement about reliability.

The proportionate position is therefore specific. Treat ICC as a real regional technology and network operator with stronger public evidence than its compressed English directory name suggests. Treat INCL as the ISP brand and AS18121 as current network evidence. Treat Hakusan as a credible physical anchor. Then require the ordered service to show its exact platform, path, data placement, recovery result and human escalation chain.

Operating assurance does not come from choosing between the warm familiarity of a local computer centre and the scale implied by modern cloud language. It comes from seeing whether the company, network, facility, software and people remain joined when a platform changes or a system fails. ICC's public record supplies most of the pieces. The customer's task is to make them meet at the workload, and to test that they stay joined under pressure.