Migration Intake
Read in an existing rule set as an export or directly through the previous system's interface. It is read-only, nothing changes at the source, and the imported data is deleted again once the process is complete.
Almost no company rolls out Zscaler onto a blank slate. There is already a rule set with its own history, and sites that don't all look the same. CentaurNexus turns the rollout into a path that works the same way for every site: with full administrator rights, you see in advance who a new rule affects and which rule has been hiding another one for months, and every single change can be undone again.
Zscaler's own tools can handle every individual step: connecting a site, writing a rule, releasing an access. What's missing is the bracket around it: the same sequence for every site, a dry run before go-live, and a way to handle what is already there. Because almost nobody truly starts from zero: there is a rule set with its own history, exceptions that once had a reason, and sites that aren't all built the same way. The features below address both sides, in the order you need them.
Whether it comes from another system or from a further Zscaler environment: an existing rule set can be read in and assessed rule by rule, before anything is transferred.
Read in an existing rule set as an export or directly through the previous system's interface. It is read-only, nothing changes at the source, and the imported data is deleted again once the process is complete.
Decide rule by rule: keep it, discard it, or set it aside. What can be transferred safely and what needs a closer look is distinguished from the start.
Once the target is ready, the transfer follows the same principle as the rest of the rollout: in traceable steps, with a backup beforehand and proof afterward.
The approved rules move over wave by wave. Every wave is preceded by a backup, and at the first disruption the transfer stops instead of continuing with an unclear outcome.
After the transfer, the result is read back, not just reported. Every rule shows whether it actually arrived, not just whether the write operation completed without an error.
What was kept, what was discarded and why, and who approved it and when: as a record that still holds up after the process is complete.
From here, the path is the same whether a rule set comes with you or everything is built fresh: onboarding doesn't start with the first rule, but with a state you can return to. Both are an action, not a project.
The rule state before the change, captured as a snapshot. If a wave goes wrong, you don't discuss what it looked like before, you see it.
Create and maintain sites without every entry having to travel by hand into the vendor's console. Identical sites are built identically.
Connecting a site rarely fails because of the technology. It fails because the second site is done differently from the first.
Connect a site, from tunnel to release. The path is the same for site one and site forty.
Roll out privileged access, for administrators and service providers. Who may access what is defined before the access exists.
A rule that works in testing can lock out someone in production that nobody thought of. Full administrator rights don't answer that on their own: both checks below are read-only, they change nothing, and they give you the answer before the rule goes live.
For private application access: enter a user, group and target, and see which rule applies. Before you flip the switch, not afterward in a ticket.
The same for the internet access rule set: which rules contradict each other, which have been hiding each other for months, which never apply.
An onboarding that runs through in one go has no point where anyone can object. Three features form the path from planning to activation.
Plan waves: who goes first, who follows, and how you can tell a wave held up.
The changes in a wave as a package, approved as a whole and executed as a whole.
The moment of going live, for internet access and branch connectivity in one place instead of separate views.
The most common finding after an onboarding is not an error, but a silent deviation that nobody reported. And if something is off after all, the whole wave doesn't have to go back.
Today's state against the state right after the wave. What has drifted is shown by name, not as a number in a bar chart.
Undo a single change on its own, even if it was made directly in Zscaler. The rest of the configuration stays untouched.
CentaurNexus requires an existing Zscaler environment and builds on top of it, including when taking over an existing rule set. The features above take the repetition off your hands and make the state visible. The decision which rule to keep, which site moves when, and which rule should apply remains yours.
These features, from Migration Intake through Migration Report, belong to the Enterprise package and can also be booked on their own, as a separate package called Migration & Onboarding, for anyone who needs exactly that and nothing else. This is not a higher tier of Light, Starter or Advance, but its own narrow package built for this purpose. You can work out which option fits your project on our pricing page.
Everything above, you use with your own team, step by step, site by site. If you would rather hand off the rollout, analysis, planning and execution included: SourcingBlox takes care of it as an official Zscaler partner, with CentaurNexus as the same tool running in the background.
In a 45-minute conversation, we go through your specific case: what you bring with you, what gets built fresh, and what stays in your hands.