- Claridis
- Any sector
Know the network you are acquiring.
An integration team has to understand a network it did not build, often with little documentation and limited access.
A cloud-first acquirer, a traditional estate.
Claridis runs on premises, on a host the acquirer controls at the acquired company’s site. It does not connect to Azure or to any Fortinet service. It reads the acquired estate and installs nothing on its devices; it changes a device only through its optional Automation feature, when you authorise the change, and in this scenario your team makes every change.
The acquired company today
A data centre or server room with core switches, firewalls, servers and virtual hosts; branch offices with routers, switches and firewalls from several vendors; its own WAN links between sites, wireless, and possibly building or plant systems.
Claridis, at the acquired company’s site
It discovers the acquired estate read-only and hands inventory, diagrams, address data, configuration records and design drafts to the integration team, which reviews and signs off each output and applies each wave with its own tools.
The acquirer’s model
Workloads in Microsoft Azure in a hub-and-spoke design, and no data centre of its own. Every branch connects to the Azure hub through a FortiGate, over VPN tunnels or SD-WAN.
- Read-only discovery over SSH and SNMP
- Designed by your engineers from the acquired estate
From the acquired estate to your Azure and FortiGate model.
Claridis gathers and organises the evidence; your engineers choose where each part lands.
Branch routers and firewalls
maps to Your standard FortiGate branch build
Your team rebuilds each branch and connects it to your Azure hub, whether the hub uses an Azure VPN gateway or a FortiGate in the hub.
Data-centre networks
maps to Azure spokes
With subnets, security rules and routes through your hub, for the workloads you choose to move. Your own migration tools move the servers and applications; Claridis does not move them.
Overlapping address ranges
maps to Re-addressing or NAT
Wherever acquired ranges overlap with your Azure address plan, as your engineers choose for each overlap.
Old WAN links, data-centre network and firewalls
maps to Retired after cutover
When your team confirms each wave.
How much evidence each device yields depends on its vendor and platform, as stage 3 explains.
Evidence and decisions, part by part
| In the acquired estate | Evidence from Claridis | Decided by your integration team |
|---|---|---|
| Branch and data-centre firewalls | The stored, redacted running configuration of the firewalls Claridis collects from, including FortiGate, Cisco ASA, Palo Alto Networks and Check Point, with their interfaces and routes for the platforms Claridis interprets, and the policies between a FortiGate’s zones. Planned, not in the current release: the rest of their firewall policies | Your standard FortiGate branch build and model for each branch, what the hub or the Azure security rules take over from the data-centre firewalls, and how each rule is rewritten in your policy standard |
| Routers and WAN links | Routing peers and next hops on the topology, and any links your engineers mark as carrier links | The tunnels or SD-WAN from each branch FortiGate to your Azure hub, according to your hub design, and when each old link is retired |
| Data-centre and branch switching, VLANs | VLANs, VLAN-to-port assignments and Layer 2 neighbours | Which data-centre segments become Azure spokes and which are retired, and how each branch’s VLANs map onto your branch build |
| Address plan | IPAM prefixes, utilisation and duplicate-address conflicts | Address spaces in your Azure address plan for the new spokes and branches, and re-addressing or translation wherever the acquired ranges overlap with yours |
| Servers and virtual hosts | Discovered hosts and the vSphere and Hyper-V inventory | Which workloads move to Azure with your own migration tools, and which are retired |
| Software and risk | Software versions, end-of-life findings for the platforms Claridis recognises, and opt-in CVE matches | What is replaced or patched before a site is connected to your hub |
| Building and plant systems | Identification-only results for OT devices | How they stay segmented behind the branch FortiGate or are retired |
Why collecting the acquired estate is hard.
The team needs an evidence-based picture of a business that is still trading, without disrupting it.
Documentation that does not match the network
Diagrams and spreadsheets are often out of date or missing, and record what was intended rather than what is running.
Knowledge that leaves with people
The engineers or provider who built the network may not stay through the transition.
Two different operating models
A multi-vendor data centre and WAN, and a decision for every part on where it lands in your model.
A security posture you cannot yet see
Versions, firewall rules and management access need review before a site joins your hub.
Overlapping address space
Acquired ranges may already be in use in your Azure address plan.
Confidential data and limited access
Configurations should not be copied into an outside service, and access is often time-bound.
From installation to cutover, in six stages.
Each stage builds on the one before.
Install
Claridis runs on hardware the acquirer controls, at the acquired company’s site.
Prepare
A separate space for the acquired company, and an agreed scope.
Collect
Claridis asks devices what they already know. Collecting installs nothing and changes nothing on them.
Produce
An inventory, maps and records to work from, all generated on the appliance.
Plan
Your engineers decide where each part of the acquired estate lands; Claridis supports them.
Cut over
Your team moves the sites in waves; Claridis shows what changed after each one.
- Understand the acquired estate
- Integrate into your Azure and Fortinet model
Stage 1: Install Claridis at the acquired company’s site
The acquirer has no data centre of its own, and Claridis is not offered as a cloud service, so the acquirer installs it on hardware it controls at the acquired company’s site, where it can reach the acquired networks.
You provide
- A host that the acquirer controls, to run the Claridis appliance.
- A place for the host at the acquired company’s site, such as its data centre or server room, with routed access to the acquired networks.
- A Claridis licence from us for the work and for the size of the acquired estate.
What Claridis does
- Checks that its software is signed by FTSTECH before the installation changes anything, so only unaltered software reaches the acquired site.
- Checks its licence on the appliance, without a connection to FTSTECH.
- Serves its console over HTTPS from the start, with a certificate created on the appliance, and accepts your own certificate.
- Makes the first administrator replace the initial sign-in credential and enrol an authenticator app.
- Keeps every outbound connection, such as vulnerability feeds, log forwarding and external AI, switched off until you enable it.
- Takes signed, encrypted whole-appliance backups, with an optional copy to your own SFTP server.
Stage 2: Prepare the appliance for scans
You provide
- Written authorisation from the acquired company to scan and collect from its devices, with an agreed scope: its address ranges, any ranges that must not be touched, and the time window.
- Read-only accounts on the acquired devices and, optionally, on its virtualisation platforms.
- People with the engineer or administrator role in Claridis to run scans.
- Accounts for the integration team’s engineers inside the acquired company’s organisation; its device configurations are visible only there.
- A VPN tunnel to any acquired network that is not routed to the appliance.
- An agreed plan for the appliance during discovery: keep it for the acquired company, or, if other organisations on it use the same private address ranges, agree the order of the scans with our team.
What Claridis does
- Holds the acquired company in its own organisation, so its scans, credentials, schedules and captured configurations stay apart from the acquirer’s data.
- Never shows one organisation’s device configurations to another, including the default administrator.
- Stores credentials encrypted at rest; a secret can be replaced but is never displayed again.
- Tests each SSH credential on the device and records it as read-only or read-write from what the device reports, so you can confirm that the access you were given is read-only.
- Applies crawl boundaries: ranges a crawl never enters, even inside its scope.
- Binds a scan or crawl to a VPN tunnel interface to reach a remote network.
Stage 3: Collect: what the scan needs, and what it gathers
You provide
- Network access from the appliance to each acquired network in scope, including any firewall openings its read-only probes need. Our team confirms what is needed for your environment.
- The documents you already have: diagrams, spreadsheets, Visio files and saved device configurations.
What Claridis does
- Sweeps the address ranges in scope, at Layer 3 or at Layer 2 with neighbour data, to find the devices that answer.
- Crawls outward from one seed device through CDP and LLDP neighbours, routing next hops and OSPF, BGP and EIGRP peers, within the scope you set.
- Captures running configuration, inventory and Layer 2 and Layer 3 tables read-only, with secrets redacted before storage. Every command passes a read-only allow-list.
- Collects from network devices of many vendors with built-in read-only command sets, firewalls included, such as Fortinet FortiGate, Cisco ASA, Palo Alto Networks and Check Point.
- Interprets firewall configurations, such as those of Cisco ASA, Fortinet FortiOS, Palo Alto Networks PAN-OS, Check Point and Juniper SRX, to read their interfaces and routes, and the policies between a FortiGate’s zones. How deeply each platform is interpreted varies, and we can tell you what to expect for the vendors in the acquired estate. Planned, not in the current release: the other firewall policies of these platforms.
- Sends operational-technology devices identification requests only; deeper OT protocols stay off unless you enable them.
- Mines uploaded documents offline for devices, cabling and subnets. Nothing reaches the inventory until an engineer reviews it.
Stage 4: Produce the data
You provide
- Engineers to review mined documents and decide which discovered devices to add to the inventory.
- An administrator in the acquired company’s organisation to export its reports.
- Your Location and Site structure for the acquired company.
- A decision on whether to enable an opt-in vulnerability feed, or a local mirror of one.
What Claridis delivers
- An asset inventory by Location and Site, with role, vendor, platform, management address and software version, including vSphere and Hyper-V hosts.
- An evidence-based topology at Layer 2 and Layer 3, exportable as PDF, PNG, SVG or Visio.
- Impact analysis: blast radius, failure sets, path impact and single points of failure.
- IPAM built from discovered data, never invented: prefixes, addresses, utilisation, VLANs and duplicate-address conflicts.
- Configuration history, with the differences between captures and a drift feed.
- Hardening checks drawn from CIS Level 1 and DISA STIG guidance for Cisco IOS, IOS-XE and NX-OS. Planned, not in the current release: your own rule packs on the same engine, so you will be able to check the acquired estate against your standards.
- Reports as CSV, JSON or print to PDF, with every download recorded in a tamper-evident audit trail. Planned, not in the current release: evidence reports, including a change log and a compliance trend.
- Planned, not in the current release: an as-built pack for the acquired organisation or any of its sites, generated from live discovery: topology diagrams, inventory with end-of-life status, interfaces and cabling, VLAN, VRF and IP plan, routing summaries, firewall summaries for the platforms Claridis interprets, and a list of gaps. Every fact will carry its evidence, and each pack will be signed, versioned and compared with the last one.
Stage 5: Plan the integration: branches to FortiGate, the data centre to Azure
With the acquired estate documented, the integration team plans where each part lands in the acquirer’s model: each branch on the standard FortiGate branch build with its tunnels to the Azure hub, each data-centre segment the acquirer moves as an Azure spoke, every address overlap resolved, and the order of the waves. Claridis supports that planning; your engineers make the decisions.
You provide
- A design project created in the acquired company’s organisation, with your Azure address plan and standards entered as its reference and requirements.
- Your standard FortiGate branch build and your hub design: how branches connect to the Azure hub, and whether the hub uses an Azure VPN gateway or a FortiGate in the hub.
- Your Azure address plan for the hub and its spokes, and your reference devices.
- The Fortinet and Microsoft reference guides you are licensed to use, loaded into the Claridis vendor library. No vendor guides ship with Claridis.
- Your integration standards: security zones, naming and approved services.
- Decisions on which data-centre workloads move to Azure and in which waves the sites move.
- Engineers to review and approve every draft.
What Claridis does
- Grounds the project’s AI drafts on the acquired company’s discovered network, read-only. Planned, not in the current release: a project intake in which you will pick the acquired devices, mark the project as brownfield, and choose a lift-and-shift, parallel-build or in-place approach.
- Design Studio drafts requirements, high-level and low-level designs, a migration plan, runbook, rollback and test plan with the AI on the appliance, and renders a cutover plan from your change records.
- Drafts the low-level design as an AI draft in FortiOS syntax when you choose FortiOS as the target and a Fortinet guide is loaded in the project. Values the guide does not cover stay as placeholders for your engineers to complete and check. Without a guide, the draft stays vendor-neutral.
- Proposes a segmentation ruleset over your real address segments, with every address written from IPAM rather than by the model and an explicit default deny, for your engineers to express as FortiGate policy.
- Drafts a vendor-neutral Terraform scaffold (virtual networks, subnets, route tables and security groups) for your engineers to adapt to Azure.
- Builds a bill of materials from the FortiGate models and Azure services your team enters.
- Planned, not in the current release: a vendor migration planner in Design Studio, working in the acquired company’s own organisation. For the platforms Claridis interprets, it will map each discovered device and its role, with its addresses, policies, NAT, routes and VPNs, onto your own standard builds. You will enter your standards in the project and supply the rest as files: a configuration backup of an existing FortiGate, an export of your Azure templates and your address plan. In its design, the planner:
- Maps each acquired branch’s routers and firewalls onto your standard FortiGate branch build, and plans its tunnels to your Azure hub, whether the hub uses an Azure VPN gateway or a FortiGate in the hub.
- Maps each acquired data-centre segment you choose to move onto an Azure spoke, with its subnets, security rules and routes through your hub.
- Recommends a target family and one of your standard builds for each device, never a FortiGate model or a price; any Azure service tier comes from your own standards. Anything it cannot map from evidence is flagged for your engineers to decide.
- Compares the acquired address ranges with your Azure address plan and plans re-addressing or NAT wherever they overlap, as your engineers choose for each overlap.
- Writes FortiOS configuration files and Azure Resource Manager (ARM) templates for your engineers to review, with a ledger in which every source object is marked as translated, transformed to meet your standard, flagged for a decision or listed as unsupported. Code, not the AI, writes every address and configuration line.
- Checks the files offline: against rule packs drawn from the published FortiOS and Azure references, against platform rules with their sources cited, for clashes with the files you supplied, by reading the generated files back, and by comparing rule by rule what the old and new rules allow and deny, with a count of the rules it could compare fully, partly or not at all. It also checks that both ends of each branch tunnel agree: the branch FortiGate and the hub carry matching address ranges and encryption settings. The files are checked offline only: they are not tested on a FortiGate and not deployed to Azure.
- Exports nothing until an engineer signs off, and nothing while a check reports an error. The planner writes files only: it does not connect to Azure or to any Fortinet or Microsoft service, and it does not apply a change. Your team runs its own checks from the hand-off checklist and applies the change.
- Exports a draft only after an engineer approves it, as PDF, Word, HTML or Markdown (diagrams also as SVG or Visio), or as one project pack.
- Planned, not in the current release: a read API and a command-line tool inside your perimeter, so your existing tooling will be able to use the discovered inventory, sites, IPAM and links.
What Claridis does not do
- Connect to, discover or change your Azure environment or any Fortinet or Microsoft service.
- Apply changes in this scenario. Your engineers review every draft and file, and apply each change with their own tools.
- Recommend specific FortiGate models, Azure service tiers or prices.
- Move servers or applications to Azure. Your own migration tools do that.
Stage 6: Cut over and verify, wave by wave
Your team moves the acquired sites in waves and applies every change with its own tools. Claridis supplies the project’s plans, a cutover plan rendered from the change records for the waves, and a read-only view of what changed at the acquired sites after each wave. When a wave is confirmed, your team retires the old WAN links, data-centre network and firewalls it replaced.
You provide
- The change records for each wave, captured in the design project, for the cutover plan.
- Your own change process, tools and maintenance windows to apply each wave to the branches, the hub and Azure.
- Read-only access, within the agreed scope, to the acquired company’s devices that stay in place after each wave. A re-scan of a site after a wave also reaches the new FortiGates there and records them in the acquired company’s organisation. If the acquirer’s own devices should not be held there, limit the re-scan to the acquired devices that stay in place, and keep that organisation to the integration team’s accounts.
- Engineers to review each comparison and decide when the old WAN links, data-centre network and firewalls are retired.
What Claridis does
- Supplies the migration plan, runbook, rollback and test plan drafted for the project in stage 5, and renders the cutover plan from the change records you capture for the waves.
- Saves a topology snapshot of a site before a wave. After a read-only re-scan, it lists the devices and links added, removed or re-typed since that snapshot.
- Shows the differences between a device’s configuration captures taken before and after a wave, with a drift feed of what changed.
- Reconciles an as-deployed device list, entered by your engineers or imported as a CSV file, against the design’s reference devices: matched, changed, added or dropped.
- Planned, not in the current release: the signed as-built pack, which will compare the design with the as-built state taken from live discovery.
- Planned: in the vendor migration planner, compares what was built with the plan your engineers signed off, from a fresh configuration backup or Azure export that your team supplies: matched, changed, added or missing.
What Claridis does not do
- Apply any change to the branches, the hub or Azure in this scenario. Your team applies each wave.
Tab 1: Each branch documented
Devices, links and read-only configuration captures, the basis for its FortiGate branch build.
Tab 2: Each data-centre segment documented
VLANs, prefixes and hosts, the basis for deciding its Azure spoke.
Tab 3: Address ranges documented
An address plan from discovery, which the planned vendor migration planner will compare with yours to find each overlap.
Tab 4: As-built checked against the design
The as-deployed device list your engineers enter, reconciled with the design. The planned as-built pack will add a signed, versioned record from live discovery, with its evidence.
Tab 5: A clear path to each wave
Approved design drafts and a cutover plan. The planned vendor migration planner will add configuration files checked offline for your engineers to review.
Tab 6: Each wave checked
Snapshots and configuration history before and after. The planned vendor migration planner will add a check against the signed-off plan from exports your team supplies.
What the integration team can expect.
With the prerequisites in place, this is the result to plan for.
Who prepares what, before you start.
| Item, by who holds it | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|
| The acquirer | ||||||
| A host for the Claridis appliance, and a Claridis licence from us | stage 1 | |||||
| Integration team accounts in the acquired company’s organisation | stage 2 | |||||
| Engineers to review discovered and mined data, and an administrator to export reports | stage 4 | |||||
| Your FortiGate branch build, hub design and Azure address plan | stage 5 | |||||
| Fortinet and Microsoft guides, and your integration standards | stage 5 | |||||
| A design project, approvers, and decisions on workloads and waves | stage 5 | |||||
| Change records for each wave, and your own tools to apply them | stage 6 | |||||
| The acquired company | ||||||
| Read-only accounts on its devices and virtualisation platforms | stage 2 | |||||
| Network access and firewall openings for the appliance | stage 3 | |||||
| Existing diagrams, spreadsheets and saved configurations | stage 3 | |||||
| Both companies | ||||||
| A place for the host at the acquired site, with routed access | stage 1 | |||||
| Written authorisation, scope, out-of-bounds ranges and time window | stage 2 | |||||
| Routes or a VPN tunnel to every acquired network | stages 2 | and 3 | ||||
| Read-only access kept for the checks after each wave | stage 6 | |||||
Our team will confirm the requirements for your environment. Contact sales
Planning an acquisition or a merger?
Tell us about the estate you need to understand.