From spreadsheet to system

What it looks like to set up identity governance for the first time. How to move off spreadsheets, Slack triage, and checklists to an actual system, without losing what already works.

7 min read · Last updated June 2026

You don't have a tool. You have a runbook in Notion, a spreadsheet that nobody touches between audits, a Slack channel where people request access, and a checklist for offboarding that the IT manager runs from memory. It works. Mostly. The audits get done. The new hires get access. The departures get handled within a few days.

This is what most companies between 50 and 300 people look like. It's not a failure. The tools weren't built for your size. They are now.

This guide is for teams making the move from manual processes to Iden. Not because what you have is broken. Because it's about to be.

What changes day one

Three things shift the moment Iden goes live.

You stop running the offboarding checklist. The HRIS marks someone as departed, Iden handles every connected app in seconds, you see the result on a dashboard the next morning. The checklist still exists, in case you want it for reference, but it's no longer the system.

You stop triaging access requests in Slack. New hires get their birthright apps automatically. Ad-hoc requests go through a real request flow with routing, approval, and an audit trail. The Slack channel becomes a place for the questions that aren't access requests.

You stop dreading audit week. The access review and offboarding trails are continuous. The auditor asks, you export. The week-before-audit panic disappears because there's nothing to scramble. The evidence has been assembling itself the whole time.

The HRIS stays. The SSO stays. The runbooks stay (frozen, for reference). The Slack channel stays for actual questions. The migration replaces the manual layer, not your stack.

Concept mapping

The mental shift is from "things people do" to "things the system does." Each manual process has an Iden equivalent.

| Manual process | Iden | |---|---| | Offboarding checklist run by IT | Zero-touch offboarding triggered by HRIS | | New hire welcome email and ticket | Birthright access provisioned automatically | | Slack: "can someone give me access to X?" | Access request with approval routing | | Quarterly access review spreadsheet | Continuous or quarterly access reviews | | Tribal knowledge in a Notion doc | Policy plus audit trail in Iden | | "Who has access to Y?" investigation | Live entitlement dashboard | | Audit prep week | Continuous evidence assembly |

The biggest shift is from "we ran the process and hope nothing got missed" to "the system runs the process and the audit log proves it."

The playbook

Five phases. Three weeks of clock time for most teams. Less in active work.

1. Inventory what you're doing manually

List the processes. The offboarding checklist (which apps are on it, who runs it, how long it takes). The onboarding flow (who triggers it, what apps go out automatically versus manually). The access review process (which apps, which managers, when). The Slack request channel (typical volume, response time). Anything else handled by a runbook or a known-by-Joe institutional fact.

This is the most important phase. The inventory is what tells Iden what to replace. Most teams discover they have more manual processes than they thought.

2. Connect HRIS and apps

The HRIS is the source of truth. Iden connects to Workday, BambooHR, Personio, Rippling, HiBob, or whatever you use. Then the apps. First 15 in under an hour. The rest over the next few days.

If you don't have an HRIS, the inventory itself becomes the source of truth. Iden has a contractor-and-employees model that doesn't require an HRIS, just a structured list. Most teams add an HRIS within their first year anyway.

3. Define birthright and policies

This is the conversation: what does a new hire actually need, on day one, by role? In manual mode this lives in someone's head or a welcome-email template. In Iden it becomes a policy. The policy fires for every new hire of that role.

Most teams get this done in a few hours. The teams that take longer are usually re-litigating which apps each department should have, which is a worthwhile conversation that just shouldn't block the migration.

4. Parallel run

The spreadsheets keep running while Iden takes over. Two to four weeks. Both systems produce records. You check that Iden is doing what the checklist would have done, or, more often, that Iden is doing things the checklist missed.

The parallel run is the audit-trail handoff. The last manual review and the first Iden access review run on overlapping windows. Compliance evidence stays continuous.

5. Archive, don't delete

The spreadsheets and runbooks get archived, not deleted. You'll want them for the first audit after migration, because the auditor will ask about the period before Iden. The Notion docs stay. The Slack channel stays. The runbooks move into a "historical" folder with a date stamp. Iden takes over as the live system.

Most teams archive after the first full quarter on Iden. The runbooks stop being load-bearing within the first month.

Common gotchas specific to manual-process migrations

A few patterns we've seen.

The shadow apps. The SaaS marketing signed up for last quarter without telling IT. The growth team's analytics tool nobody else uses. The reporting platform finance bought directly. These don't show up in the offboarding checklist because IT didn't know they existed. The first migration step that finds them is a SaaS discovery scan. You'll find more than you expect.

The HRIS that "everyone calls the source of truth" but isn't. Common pattern: HR uses BambooHR for some things, payroll lives somewhere else, contractor records are in a separate spreadsheet. Before migration, reconcile. After migration, the HRIS is the trigger. If data is wrong there, nothing downstream works right.

The "this is how we've always done it" stakeholder. Whoever has been running the manual processes the longest may resist replacing them. Often justifiably; they know the edge cases. Bring them into setup. Their context is what keeps the system from replicating the manual process incorrectly.

The contractor lifecycle that lives in someone's Notion doc. Contractors are usually the messiest part of manual identity. They don't fit in the HRIS, they don't fit in the offboarding checklist, they're tracked by whoever hired them. Iden has first-class contractor identity. This part of the migration usually unlocks the single biggest quality-of-life improvement.

The first audit after migration. The auditor will want evidence for the period before Iden. Be ready with the archived spreadsheets, the runbook screenshots, the Slack export. Iden produces clean evidence going forward; the pre-Iden period needs historical artifacts to fill the gap.

Timeline by stack size

Most teams fit one of these.

Small (under 100 people, fewer than 20 apps): 1 to 2 weeks. Iden setup is a couple of days. Most of the time is the inventory conversation.

Mid (100 to 500 people, 20 to 60 apps): 2 to 3 weeks. The parallel run window expands. The birthright conversation can take a few days if your team has many roles.

Larger (500 to 2,000 people, 60+ apps, multiple departments with strong local autonomy): 3 to 5 weeks. The hardest part is reconciling the various local processes (marketing has their own way, engineering has their own way). One team isn't doing it wrong, they're doing it differently. Migration normalizes the surface.

If you're outside these ranges, tell us at office hours. We'll think it through with you.

Rollback plan

The spreadsheets, runbooks, and Slack channels still exist. They're paused, not removed. If something goes wrong during parallel run, the runbook is what you fall back to. We've seen this happen exactly once. A customer hit a unique app permission model on day three of parallel run, paused Iden for that app for a week while we shipped a connector update, and ran the checklist for that one app manually. Iden took over the next week.

After full cutover, the rollback is "re-run the spreadsheet processes." It's there. Most teams never use it.

Where to ask for help

Migration office hours run weekly. The same team that builds Iden runs them. Bring your inventory (or come without one and we'll help build it), your timeline, and the people who've been running your manual processes. The folks closest to the work give us the most useful information.

Frequently asked questions

We don't have an HRIS. Can we still use Iden?

Yes. Iden has a contractor-and-employees model that works without an HRIS. The structured employee list becomes the source of truth. Most teams add an HRIS within their first year on Iden anyway, but it's not a prerequisite.

We're a small team (under 50 people). Is this overkill?

Probably yes if you're under 50 employees with fewer than 15 SaaS apps. The math gets compelling around 50 employees or 20+ apps, whichever comes first. The pain that justifies a tool isn't headcount, it's the volume of apps in the long tail.

What about all the tribal knowledge documents. Do those become irrelevant?

No, they stay relevant for context. Iden replaces what those documents tried to enforce (who gets access to what, when revocations should happen). The 'why this app does it this weird way' notes stay in your Notion. The 'who has access' lives in Iden.

We've tried automation before and it broke. Why is this different?

The usual reason DIY automation breaks is the long tail of apps the automation can't reach. Iden was built for that long tail specifically: non-SCIM apps, internal admin panels, custom systems. If your previous automation broke because it stopped at the SCIM 20%, the coverage gap is what's different now. If it broke because requirements kept shifting, that's a process problem; we'll think it through with you.

How does Iden handle the SaaS apps marketing or finance signed up for without IT knowing?

Discovery is part of setup. Iden surfaces shadow SaaS through payment data and browser signals (with consent). The first list usually surprises the IT team. From there, you connect the ones that need governance and acknowledge the ones that don't.

What about contractors who aren't in any system today?

Iden has a contractor identity model with end-date triggers. You add the contractor as a record with an expected exit date. The offboarding fires on that date whether or not the contractor was ever in the HRIS. This is the single biggest quality-of-life win in the manual-to-Iden migration.

SOC 2 audit coming in 3 months. Is that enough time?

Yes. Most teams are audit-ready within 2 weeks of go-live. The harder question is what evidence the auditor needs for the period before Iden, archived spreadsheets, runbook screenshots, the email trail. Plan a few hours of historical-evidence cleanup as part of migration prep.

Will we need to change our HRIS, SSO, or ITSM?

No. Iden plugs into whatever you have. If you're considering changing those tools, the migration to Iden is independent. You can sequence them in either order.

We have a manager who doesn't trust the system yet. How do we handle that?

Run parallel. The manager keeps their spreadsheet, Iden runs alongside, both produce results. After two cycles, the system has earned the trust or it hasn't. We've seen the manager become the strongest advocate by week three, more often than not. (Sometimes it doesn't work. We'll tell you when.)

What about the spreadsheets we still need for auditor reference?

Archive them. Keep them accessible. Iden produces evidence going forward; the historical spreadsheets cover the period before. Most auditors are happy with the handoff once they see the structured trail Iden produces.