Migrating from Oasis Security to a Unified NHI Platform

Oasis is a good discovery product. That is not the debate. The debate — the one every security architect running Oasis is now having with procurement — is whether to keep it as a point solution or consolidate it into a platform that also does secrets, TIDR, and AI agents.

For teams that decide to consolidate, this is what the migration actually looks like.

The consolidation decision typically follows a predictable pattern. A team buys Oasis for discovery and posture. They get value from it — the inventory is real, the posture scores help prioritise remediation. Then they buy a secrets scanner. Then they add a SIEM rule for identity anomalies. Then an AI agent problem emerges and there is no good answer. At some point a CISO or a security architect draws a line and asks: "how many point tools can we operate before the overhead of the tool stack exceeds the value it delivers?"

The answer varies, but three dedicated NHI tools tends to be where teams start seriously evaluating consolidation. This guide is for teams that have made that decision and want to execute the migration without breaking coverage.

What you are actually migrating

Before diving into phases, it is worth being precise about what moves in a migration from a discovery-and-posture tool to a unified platform. There are three distinct data types, and each has a different migration strategy.

The reason inventory data is re-discovered rather than imported is data freshness and provenance. An imported record has no provenance trail — you do not know which connector discovered it, when, or with what confidence. A re-discovered record has all of that metadata, and the graph model can track its evolution over time. Starting from a clean discovery baseline is a better long-term foundation than inheriting a potentially stale export.

Phase 1 — parallel discovery

• TigerIdentity connectors are stood up against the same sources as Oasis (cloud IAM, secrets managers, Kubernetes, source control).
• Both systems run in read-only mode.
• Coverage is reconciled: every NHI in Oasis must appear in TigerIdentity. Any delta is investigated before proceeding.

Coverage reconciliation is the critical gate at phase 1. "Every NHI in Oasis must appear in TigerIdentity" sounds simple but requires a systematic comparison. Oasis and TigerIdentity may use different deduplication logic, different naming conventions, and different scoping for what constitutes an NHI. Discrepancies fall into three categories:

• In Oasis, not in TigerIdentity. A connector is not yet configured, or the deduplication logic differs. Investigate and resolve before proceeding.
• In TigerIdentity, not in Oasis. TigerIdentity discovered something Oasis missed. This is expected — it demonstrates the value of the migration and does not block the phase gate.
• Both present, different attributes. Owner attribution may differ, or posture classification may diverge. Document the discrepancy; use TigerIdentity's version as the canonical record going forward.

Phase 2 — policy translation

The remediation workflow translation is where the most significant change in behaviour occurs, and it deserves explicit stakeholder communication. In Oasis, a posture alert creates a ticket or a notification. In TigerIdentity, the same trigger can execute a remediation action — rotate the credential, quarantine the identity, or notify the owner with an actionable DM rather than an alert in a queue.

That shift from alerting to enforcement is the core value of consolidation, but it also means that misconfigured policies have real consequences rather than just creating noise. Phase 2 should include a policy review with the identity team and, for high-impact policies (anything that can revoke a session or rotate a production credential), a staged roll-out with a dry-run period.

# Example: Oasis posture rule translated to TigerIdentity YAML DSL

# OASIS (conceptual export format):
# rule: credential_age_alert
# condition: credential.last_rotated_days > 90
# action: create_ticket(priority=P2)

# TIGERIDENTITY equivalent:
policy:
  name: credential-age-governance
  scope: [ServiceAccount, ApiKey, Secret]
  rules:
    - condition:
        last_rotated_days: {gt: 90}
        environment: {in: [production, staging]}
      actions:
        - notify_owner:
            channel: slack
            template: credential-age-warning
        - set_posture_score: C
    - condition:
        last_rotated_days: {gt: 180}
        environment: production
      actions:
        - notify_owner:
            channel: slack
            urgency: high
        - set_posture_score: F
        - quarantine_if_idle: {idle_days: 30}
        # Note: enforce rotation for enrolled credentials
        - trigger_rotation:
            if: enrolled_in_managed_rotation

Phase 3 — dual-run

For a minimum of two weeks, both platforms observe the same environment. Alerts and posture reports are compared daily. Any divergence — a signal Oasis fires that TigerIdentity misses, or vice versa — is triaged.

The dual-run comparison should be systematic, not ad hoc. Establish a daily comparison ritual: export the posture-score distribution from both platforms, the alert list, and the top-10 highest-risk NHIs. If any NHI in Oasis's top 10 does not appear in TigerIdentity's top 10, that is a signal worth investigating regardless of whether the absolute scores differ.

Two weeks is a minimum because it captures at least one full week of each platform's typical weekly variation. Many security events are weekly-cyclical — code deploys on Thursdays, batch jobs on Mondays, access reviews on Fridays. A two-week dual-run catches events that occur on different days of the week.

Phase 4 — cutover

• Redirect Slack and PagerDuty routes from Oasis to TigerIdentity.
• Point compliance dashboards at TigerIdentity's reporting API.
• Enable enforcement actions (JIT provisioning, session revocation, credential rotation).
• Freeze Oasis in read-only mode for one billing cycle as a safety net; then decommission.

Cutover day is operationally straightforward if phases 1–3 have been thorough. The routing changes are configuration updates, not architectural changes. The compliance dashboard redirects are API endpoint swaps. The enforcement enablement is a policy flag flip.

The one area that sometimes surprises teams on cutover day is the notification volume. TigerIdentity's default notification configuration is often more granular than what Oasis was sending — because TigerIdentity knows about more NHIs and has more policy triggers active. Brief the identity team before cutover on the expected notification volume, and have a triage rotation ready for the first 48 hours.

Phase 5 — expand

Cutover is not the win. The point of consolidating is to add what Oasis could not: secrets governance, TIDR behavioural detection, and MCP-based AI agent enforcement. Those capabilities light up as soon as cutover completes and the identity graph is the source of truth.

A typical post-cutover expansion plan runs over 90 days:

1. Days 1–30: Secrets governance. Enrol the top 20% highest-risk secrets (by privilege and age) in managed rotation. Stand up the code-scanning connector for ongoing secrets detection in new commits.
2. Days 31–60: TIDR activation. Enable TIDR on production NHIs. Review the default detection thresholds against your actual baseline data. Tune the anomaly score thresholds before enabling automated enforcement.
3. Days 61–90: AI agent governance. Enrol all known AI agents in the MCP gateway. Run existing agents in dry-run mode for two weeks; validate policy; enable live enforcement.

By day 90, the capabilities that drove the consolidation decision are all active and validated. The team that spent six months managing three point tools is now operating a single platform with broader coverage, live enforcement, and a unified identity graph that makes every downstream question — "who can access this data?", "which agents have called this service?", "what changed in the last 24 hours?" — answerable in seconds.