You start from the assets you already have.
There are two of them, and most organizations use both. Whichever way a system arrives, it lands in your library and is governed from then on.
Scan and Import
The platform reads a live account, shows you what is there, and brings it under management as it is. Four steps.
See how it works →Your Terraform
Read and rebuilt as a Fractal, or kept as it is inside a component the platform governs. You choose per module.
See how it works →Four steps, and your estate is in.
Connect a cloud account, scan it, read the report, group what was found into Fractals. At the end everything you already run is visible in Fractal Cloud, exactly as it runs.
Point it at your infrastructure.
You add an agent for the environment you want to read: an AWS account, Azure, Google Cloud, OCI, a sovereign provider or your own datacenter. You give it credentials, choose the scope, and it is ready.
- What runs in your own datacenter is read the same way as a cloud account
- The scan changes nothing while it reads
- Several providers can be connected side by side
Read the whole stack.
The scan walks compute, storage, network, big data, edge and identity in turn. Every resource found is written to a live log, so you can follow it as it happens.
- It reads only, and changes nothing
- Minutes, not a project
- Several accounts can be scanned side by side
Read the report.
Three numbers: what was discovered, what the platform already recognizes, and what it does not. The last group does not block anything, and the table lists every resource in detail.
On its own this is already useful. Most organizations do not have one accurate picture of what runs across their datacenter and their cloud accounts, and this produces one in minutes.
Group what was found into Fractals.
The platform proposes a grouping, and you correct it. Anything it could not place is dragged into the Fractal it belongs to, and you can create new ones. This is where your knowledge of the estate is captured.
- What comes out are named Fractals, not a flat inventory
- Nothing is deployed or changed at this point
- You can change the grouping at any point
A design you can reuse, or the estate as it runs.
At the end of the four steps you decide what each system becomes. The difference matters.
A reusable design
The architecture becomes a versioned design you can review on a canvas, edit if you want, and deploy again as many times as you need.
The running estate, governed
What is already running is brought under management as it is, so it gains versioning, reconciliation and controlled updates without being recreated.
Both routes end in the same place: your own architecture, versioned, in your library. Deploying it somewhere else is a separate decision, and a separate story, see running it where it has to run.
The Terraform you have keeps running.
Scanning a cloud account is one way in. The other is the code you already wrote. Two routes, and neither throws anything away.
Four situations this was built for.
Leaving a datacenter
You know what runs on your own hardware, roughly. Reading it properly and rebuilding it on a cloud is usually the longest part of the move. Here it is the same design, deployed again.
Inheriting an estate
After an acquisition, or when a team changes hands, you get accounts nobody can fully describe. The scan gives you the picture, and the import gives you control of it.
Proving where things run
An auditor asks what exists and where. An inventory produced by a scan, kept current afterwards, is a better answer than a spreadsheet maintained by hand.
Standardizing what exists
The architecture your best team already built becomes the design every other project starts from, instead of a repository the others copy and slowly change.
Begin with one environment
Connect one provider, run one scan, and see your own infrastructure come back as something you can deploy again. Everything after that is your decision.