Migration Guide

How to Migrate from Trend Cloud One to Vision One — 2026 Guide

Trend Cloud One has reached end of life and its capabilities now live in Trend Vision One. If you are still running a Cloud One tenant, this is a migration you schedule rather than one you improvise during a renewal call. The good news is that it is largely a re-registration exercise — the agents on your servers mostly stay where they are and get pointed at a new tenant — rather than a rip and replace. The work that takes time is policy review and verification, not deployment. Here is the sequence we run for Indian customers.

Steps

Step 1 — Inventory what you actually have in Cloud One: Export the full list of protected instances, the modules enabled on each (anti-malware, IPS, integrity monitoring, log inspection, firewall), your policy tree, and any automation using the Cloud One API. This inventory is the acceptance test for the migration — you cannot confirm nothing was lost if you never wrote down what you had. Note which instances are still running and which are stale entries for machines that were decommissioned months ago; migrations are a good moment to stop paying for those.
- Export policies and rule assignments, not just the instance list
- Flag every integration or script that calls the Cloud One API
- Identify stale agents now — they inflate the new licence sizing
Step 2 — Create and configure the Vision One tenant: Create the Vision One account, choose the data region, and set up user roles before anything connects. Region choice matters for Indian customers with data residency conditions, and it is not something you want to revisit after you have onboarded three hundred servers. Configure role-based access so the operations team, the security team and any external partner have appropriate scopes from day one rather than everyone sharing an admin login.
- Decide the data region before onboarding anything
- Set up SSO and roles at the start, not after go-live
- Keep the Cloud One tenant live in parallel during the transition
Step 3 — Map Cloud One entitlements onto the credit model: Vision One licenses through credits rather than per-product SKUs, so your Cloud One entitlement has to be converted into a credit pool sized for the same estate plus headroom. Get the conversion rate for each capability written into the quote — this is the number that decides whether the pool covers your fleet, and it is set in your entitlement rather than published. Size for what you expect to run next year, because a mid-term top-up is priced at whatever applies then.
- Ask for the credit conversion rate per capability in writing
- Size the pool for year two, not for migration day
- Model XDR data ingestion separately — it is billed per GB
Step 4 — Connect a pilot group of servers first: Pick ten to twenty servers that represent the variety of your estate — a Windows application server, a Linux web server, a database, a Kubernetes node, something in the DMZ — and connect those to the Vision One tenant first. Verify that each module reports correctly and that policies apply as expected. Do not start with the payment system. A pilot that covers your variety rather than your volume is what surfaces the surprises.
- Choose pilot servers for variety, not for how easy they are
- Verify each module separately — IPS reporting is the usual gap
- Keep the pilot running a week before scaling
Step 5 — Rebuild and review policies rather than copying them: Policies can largely be recreated, but resist a straight copy. Most Cloud One policy trees have accumulated years of exceptions, disabled rules and one-off overrides nobody remembers approving. Run a recommendation scan on the new tenant and compare its suggestions to your existing rule assignments — where they disagree, someone should decide deliberately rather than inheriting a decision made in 2021. This is the step that produces genuine security improvement from the migration.
- Run recommendation scans and diff against the old assignments
- Put new IPS rules in detect-only mode before enforcing
- Document why each surviving exception exists
Step 6 — Migrate the rest of the estate in waves: Move the remaining servers in waves grouped by application and change window, not alphabetically. Keep the Cloud One tenant connected until each wave is verified in Vision One, so you always have a working console for every server. Coordinate with application owners for anything in a regulated or production-critical path, and avoid month-end and financial year-end windows entirely for Indian finance systems.
- Group waves by application owner and change window
- Never cut over the last console until the new one is verified
- Avoid March in India — finance systems are frozen
Step 7 — Rewire integrations, then decommission Cloud One: Update anything that talked to Cloud One: SIEM log forwarding, ticketing integrations, API scripts, dashboards, and any automation that reacts to alerts. These are almost always discovered late because they fail silently. Once every integration is confirmed working against Vision One and the last wave is verified, decommission the Cloud One tenant and confirm billing has stopped. Keep the export from step one as your record of what was migrated.
- Test SIEM forwarding with a real detection, not a health check
- Check for scripts using Cloud One API keys before revoking them
- Confirm the old subscription is actually cancelled, not just unused

Frequently Asked Questions

Do we have to reinstall agents on every server?

In most cases no — the migration is largely a re-registration, where existing agents are pointed at the new Vision One tenant rather than removed and redeployed. Some older agent versions need an upgrade first, which is a normal package update rather than a reinstall. Plan for a small number of stubborn hosts that do need hands-on attention; there are always a few, usually the oldest and least documented machines in the estate.

Will we lose our policies and exceptions?

Not if you export them first, which is why step one exists. Policies can be recreated in Vision One, and the better practice is to rebuild rather than copy — most long-lived policy trees carry exceptions that no longer have a justification. Export everything before you start so you can prove what the old state was, then make deliberate decisions about what carries forward.

How long does the migration take?

For a typical Indian mid-market estate of 100 to 300 servers, plan four to eight weeks end to end. Tenant setup and the pilot take one to two weeks, policy review takes one to two, and the waves take the rest depending on how many change windows you can get. The constraint is almost never technical — it is how quickly application owners will approve a change to a production server.

Can we run Cloud One and Vision One at the same time?

Yes, and you should during the transition. Running both lets you migrate in waves and always have a working console for every server, which is the difference between a controlled migration and a risky cutover. Budget for a short period of overlap in the commercials and confirm with your partner how the overlap is handled so you are not billed twice for the same servers longer than necessary.

What changes for our team after migration?

The console and the licensing model, mostly. Vision One puts server protection in the same platform as endpoint, email and cloud, so detections correlate across layers rather than sitting in a server-only console — that is the actual benefit, and it only materialises if you connect the other layers too. Licensing moves from product SKUs to a shared credit pool, which means renewal conversations become about pool size rather than per-product counts.

Get a Trend Micro quote priced in INR with GST invoice — we size the licence, deploy it, and can run the console for you.