Home / Case studies / Company acquisition

Illustrative scenario

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. This scenario follows Claridis from installation to the cutover of each site, for an acquirer that runs its workloads in Microsoft Azure and connects its branches through Fortinet FortiGate firewalls.

About this case study

An illustrative scenario, not a customer story.

The two companies in this scenario are hypothetical. It contains no customer names, results, savings or timelines. It describes how Claridis is designed to be used for this kind of work.

Claridis is in beta, and some of the capabilities described here are still in development. We can tell you which are available in the current release.

The scenario

A cloud-first acquirer, a traditional estate.

The acquirer

Cloud-first

Workloads in Microsoft Azure, in a hub-and-spoke design
No data centre of its own
Every branch office connects to the Azure hub through a Fortinet FortiGate, over VPN tunnels or SD-WAN

The company it is acquiring

A traditional estate

A data centre or server room, with 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 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, and it never applies changes to the acquirer’s estate.

Before and after

From a traditional estate to the acquirer’s model.

The acquirer’s model on the right is the acquirer’s own design, built with its own tools.

The acquired company today, Claridis at its site, and the acquirer’s model.

Describe the drawing

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. After cutover, the WAN links, the data-centre network and the old firewalls are retired.
Claridis, at the acquired company’s site: An appliance on a host the acquirer controls 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. Claridis does not connect to Azure or to any Fortinet service.
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. Designed by the acquirer’s engineers from the acquired estate, and outlined with a dashed dark line: the acquired branches, rebuilt on the standard FortiGate branch build, and a new spoke for the acquired data-centre segments the acquirer chooses to move.

The target state, as you decide it

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

How each part of the acquired estate maps to a decision for the integration team
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, routes and policies for the platforms Claridis interprets	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

The challenge

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.

The lifecycle

From installation to cutover, in six stages.

Each stage builds on the one before, on one appliance at the acquired company’s site.

Understand the acquired estate
1
Install

at the acquired company’s site
- Signed software
- Offline licence check
- HTTPS and MFA on
2
Prepare

the appliance for scans
- Separate organisation
- Read-only logins
- Scope and boundaries
3
Collect

what the scan needs
- Scans and seed crawl
- Read-only config
- Firewall configurations
- Document mining
4
Produce

the data
- Inventory, topology
- IPAM, config history
- Signed as-built pack
Integrate into your Azure and Fortinet model
5
Plan

branches to FortiGate, data centre to Azure
- Discovery into design
- Approved design drafts
- Vendor migration planner
- Read API and CLI
6
Cut over

and verify, wave by wave
- Cutover and rollback plans
- Re-scan and compare
- Check against the design

Stage 1

Install Claridis at the acquired company’s site

Claridis runs on hardware the acquirer controls, at the acquired company’s site.

You provide

A host you control
A place at the acquired site
A Claridis licence

Our team will confirm the requirements for your environment. Contact sales

How Claridis helps

Installs only software signed by FTSTECH
Checks its licence on the appliance, offline
HTTPS and an authenticator app from the first sign-in
Every outbound connection off until you enable it

Full detail for stage 1, Install

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 FTSTECH 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

A separate space for the acquired company, and an agreed scope.

You provide

Written authorisation and scope
Read-only device accounts
Engineer accounts for your team
A VPN tunnel where needed

How Claridis helps

Keeps the acquired company in its own organisation
Never shows its device configurations to another organisation
Records each login as read-only or read-write, as the device reports it
Keeps every scan inside the agreed boundaries

Full detail for stage 2, Prepare

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

Claridis asks devices what they already know. Nothing is installed or changed on them.

You provide

Access to the networks in scope
Your existing diagrams and configurations

How Claridis helps

Sweeps the agreed ranges and crawls out from one seed device
Captures configurations read-only, with secrets redacted
Interprets firewall configurations; how deeply each platform is interpreted varies
Mines your documents offline, for an engineer to review

Full detail for stage 3, Collect

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, routes and policies. How deeply each platform is interpreted varies, and we can tell you what to expect for the vendors in the acquired estate.
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

An inventory, maps and records to work from, all generated on the appliance.

You provide

Engineers to review the data
An administrator to export reports
Your Location and Site structure

How Claridis helps

An asset inventory by Location and Site
An evidence-based topology, with impact analysis
IPAM and configuration history from discovered data
A signed, versioned as-built pack

Full detail for stage 4, Produce

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, and your own rule packs on the same engine, so the acquired estate can be checked against your standards.
Reports as CSV, JSON or print to PDF, with every download recorded in a tamper-evident audit trail, and evidence reports, including a change log and a compliance trend.
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 carries its evidence, and each pack is signed, versioned and compared with the last one.

Stage 5

Plan the integration: branches to FortiGate, the data centre to Azure

Your engineers decide where each part of the acquired estate lands; Claridis supports them.

You provide

Your FortiGate branch build and hub design
Your Azure address plan
Your integration standards
Decisions on workloads and waves

How Claridis helps

Carries discovered devices into a design project
Drafts the design, migration plan, runbook, rollback and test plan for engineer approval
For the platforms Claridis interprets, a vendor migration planner maps each device onto your standard builds and writes files for review, checked offline only
Exports nothing until an engineer signs off

What Claridis does not do

Connect to, discover or change your Azure environment or any Fortinet or Microsoft service.
Apply changes. 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.

Full detail for stage 5, Plan

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

Carries discovered devices directly into a design project: 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.
Provides a vendor migration planner in Design Studio, working in the acquired company’s own organisation. For the platforms Claridis interprets, it maps each discovered device and its role, with its addresses, policies, NAT, routes and VPNs, onto your own standard builds. You 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. 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.
Offers a read API and a command-line tool inside your perimeter, so your existing tooling can use the discovered inventory, sites, IPAM and links.

Stage 6

Cut over and verify, wave by wave

Your team moves the sites in waves; Claridis shows what changed after each one.

You provide

Change records for each wave
Your change process and tools
Read-only access to the acquired devices that stay in place

How Claridis helps

Renders the cutover plan from your change records
Compares a read-only re-scan with the snapshot before each wave
Shows configuration differences before and after each wave
Compares the build, from files your team supplies, with the signed-off plan

What Claridis does not do

Apply any change to the branches, the hub or Azure. Your team applies each wave.

Full detail for stage 6, Cut over

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.
Compares the design with the as-built state taken from live discovery, as part of the signed as-built pack.
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.

Expected outcome

What the integration team can expect.

With the prerequisites in place, this is the result to plan for. How deeply each platform is interpreted varies; our team can tell you what to expect for the vendors in the acquired estate.

Each branch documented
Devices, links and read-only configuration captures, the basis for its FortiGate branch build.
Each data-centre segment documented
VLANs, prefixes and hosts, the basis for deciding its Azure spoke.
Address overlaps found
An address plan from discovery, which the vendor migration planner compares with yours.
A signed as-built pack
Versioned, with its evidence, and compared with the design.
A clear path to each wave
Approved design drafts, a cutover plan, and configuration files checked offline for your engineers to review.
Each wave checked
Snapshots and configuration history before and after, and a check against the signed-off plan from exports your team supplies.

The outcome in full

A documented acquired estate, site by site

For each acquired branch: its routers, switches and firewalls, their links and WAN connections, and their read-only configuration captures, as the basis for its FortiGate branch build
For each data-centre segment: its VLANs, prefixes and hosts, including the vSphere and Hyper-V inventory, as the basis for deciding its Azure spoke
An address plan built from discovery, which the vendor migration planner compares with your Azure address plan to find each overlap
Firewall configurations, FortiGate included, collected read-only, with their interfaces, routes and policies for the platforms Claridis interprets
A signed, versioned as-built pack of the acquired estate, compared with the design
Diagrams and reports to share across the integration team, held in the acquired company’s own organisation

A clear path to each wave

Discovered devices carried straight into a brownfield design project
Design drafts grounded on that data and approved by your engineers, and a cutover plan rendered from your change records
A vendor migration planner that maps each branch onto your FortiGate branch build and each data-centre segment onto an Azure spoke, and writes configuration files for your engineers to review, checked offline only
Topology snapshots and configuration history to compare each site before and after its wave
A check in the vendor migration planner of what was built against the plan your engineers signed off

Decisions that stay with your team

Choosing FortiGate models, the hub design and Azure services
Deciding how firewall policy is rewritten in your own standard
Moving servers and applications to Azure with your own migration tools
Applying each wave, and approving each change
Retiring the old WAN links, data-centre network and firewalls

Readiness checklist

Who prepares what, before you start.

The acquirer

A host for the Claridis appliance, and a Claridis licence from FTSTECHstage 1
Integration team accounts in the acquired company’s organisationstage 2
Engineers to review discovered and mined data, and an administrator to export reportsstage 4
Your FortiGate branch build, hub design and Azure address planstage 5
Fortinet and Microsoft guides, and your integration standardsstage 5
A design project, approvers, and decisions on workloads and wavesstage 5
Change records for each wave, and your own tools to apply themstage 6

The acquired company

Read-only accounts on its devices and virtualisation platformsstage 2
Network access and firewall openings for the appliancestage 3
Existing diagrams, spreadsheets and saved configurationsstage 3

Both companies

A place for the host at the acquired site, with routed accessstage 1
Written authorisation, scope, out-of-bounds ranges and time windowstage 2
Routes or a VPN tunnel to every acquired networkstages 2 and 3
Read-only access kept for the checks after each wavestage 6

Our team will confirm the requirements for your environment. Contact sales

Discuss your scenario

Planning an acquisition or a merger?

Tell us about the estate you need to understand. We can walk through how Claridis would apply, what it needs from both companies and your environment, and which capabilities are available in the current release.

Explore Claridis Contact sales

Know the network you are acquiring.

An illustrative scenario, not a customer story.

A cloud-first acquirer, a traditional estate.

From a traditional estate to the acquirer’s model.

From the acquired estate to your Azure and FortiGate model.

Why collecting the acquired estate is hard.

Documentation that does not match the network

Knowledge that leaves with people

Two different operating models

A security posture you cannot yet see

Overlapping address space

Confidential data and limited access

From installation to cutover, in six stages.

Install Claridis at the acquired company’s site

You provide

How Claridis helps

You provide

What Claridis does

Prepare the appliance for scans

You provide

How Claridis helps

You provide

What Claridis does

Collect: what the scan needs, and what it gathers

You provide

How Claridis helps

You provide

What Claridis does

Produce the data

You provide

How Claridis helps

You provide

What Claridis delivers

Plan the integration: branches to FortiGate, the data centre to Azure

You provide

How Claridis helps

You provide

What Claridis does

Cut over and verify, wave by wave

You provide

How Claridis helps

You provide

What Claridis does

What the integration team can expect.

Each branch documented

Each data-centre segment documented

Address overlaps found

A signed as-built pack

A clear path to each wave

Each wave checked

A documented acquired estate, site by site

A clear path to each wave

Decisions that stay with your team

Who prepares what, before you start.

The acquirer

The acquired company

Both companies

Planning an acquisition or a merger?