If you're reading this, you're probably already running PowerShell scripts for user management. Maybe you've built an onboarding script that creates users, assigns groups, and sets licenses. Maybe you have an offboarding script that disables accounts and removes memberships. Maybe you've been maintaining these scripts for years and they mostly work.
This page is for you. Not because PowerShell scripting is wrong — it was probably the right call when you started. But there's a point where maintaining custom scripts becomes more expensive than using a purpose-built tool, and most IT teams cross that line without realizing it.
The case for PowerShell (it's real)
Let's acknowledge the strengths first, because they're genuine:
It's free. PowerShell comes with your Microsoft environment. No licensing costs, no procurement process, no vendor meetings. For a small company watching every euro, that matters.
It's flexible. You can script exactly what you need, nothing more. If your onboarding process has specific quirks — creating a mailbox with particular settings, setting obscure attributes, calling a custom API — PowerShell can handle it.
It's already there. If you have an IT admin who knows PowerShell, you can have a working script in a few hours. The Microsoft Graph PowerShell module is well-documented. The barrier to entry is low.
It builds skills. Your team learns scripting, Graph API, and Entra ID internals. That knowledge has long-term value regardless of what tools you use later.
For a 30-person startup with one IT person managing everything, PowerShell scripts are often the correct solution. No argument there.
Where PowerShell scripts start to cost more than they save
The problems usually don't arrive suddenly. They accumulate gradually until someone has a bad week.
Bus factor of one. Most PowerShell identity scripts were written by one person. That person understands the logic, the workarounds, the edge cases, and the reason lines 47 through 63 look weird but shouldn't be changed. When that person goes on holiday, changes roles, or leaves the company, everyone else is left staring at code they didn't write and don't fully understand.
No audit trail. PowerShell scripts do things, but they don't reliably record what they did, who triggered them, when, and why. You can add logging — and many people do — but building a comprehensive, tamper-proof audit trail that satisfies SOC 2 or ISO 27001 requirements is a significant engineering effort on top of the actual automation.
Error handling is an afterthought. Most scripts are built for the happy path. User creation works, groups get assigned, everyone goes home. But what happens when the Graph API returns a 429 because you hit a throttling limit? When a group assignment fails silently because a license conflict exists? When the script partially completes and leaves a user in a half-provisioned state? Robust error handling doubles or triples the complexity of any script.
Testing is manual. When you update a script, how do you test it? Typically by running it against a test user and checking the result manually. There's no unit testing framework, no staging environment, no rollback mechanism. In practice, this means scripts get updated cautiously and bugs are discovered in production.
Offboarding coverage gaps. An onboarding script is straightforward because you know what needs to be added. An offboarding script is harder because you need to remove access from everything, including things that were added manually outside the script. PowerShell can only remove what it knows about, and it doesn't know about the SharePoint site someone was added to by a project manager three months ago.
Access reviews don't exist. Scripts handle provisioning and deprovisioning. They don't handle the question "does everyone's current access still make sense?" Access reviews require a different kind of tooling — campaigns, workflows, manager approvals, exception tracking. Building this in PowerShell is theoretically possible but practically a separate development project.
Scaling is linear. Every new requirement means more code. New department? Update the script. New application? Add a section. New compliance requirement? Build new logging. The maintenance burden grows linearly, but your IT team doesn't.
What Adcyma replaces in your script collection
Adcyma isn't a scripting platform. It's a governance tool that handles the things you've been scripting, plus the things you couldn't easily script:
What you've scripted | What Adcyma provides
- User creation script | Automated provisioning based on role definitions
- Group assignment script | Rule-based group management with full visibility
- Offboarding script | Comprehensive deprovisioning including manually-added access
- License assignment script | Automatic license management tied to roles
- Custom logging | Built-in audit trail for every action
- (probably nothing) | Structured access reviews with manager workflows
- (probably nothing) | Pre-built compliance reports for SOC 2, ISO 27001, NIS2
The key difference isn't automation — you can automate in PowerShell too. The difference is governance: audit trails, access reviews, compliance reporting, and a system that doesn't depend on one person's institutional knowledge.
When to keep scripting
Stick with PowerShell if:
- You have fewer than 50 users and very low turnover
- You have no compliance requirements (no SOC 2, ISO 27001, or NIS2)
- Your IT admin who maintains the scripts isn't going anywhere
- You don't need access reviews or audit trails
- The scripts are simple, well-documented, and maintainable by the whole team
If this is your situation, keep going. PowerShell is a perfectly good tool.
When to stop scripting
Consider a purpose-built tool when:
- Your scripts have become complex enough that only one person fully understands them
- You're facing a compliance audit and can't produce clean access evidence
- You need access reviews and building them in PowerShell isn't realistic
- Onboarding or offboarding has produced a security incident (former employee access, wrong permissions)
- You're spending more time maintaining scripts than the scripts are saving you
- You're about to lose the person who wrote the scripts
This is the transition point Adcyma is designed for. You've outgrown scripting but you don't need an enterprise platform. You need something in between that works with your Entra ID environment and doesn't require a six-month project to implement.
Adcyma is free for up to 25 users. For larger teams, start a free 14-day trial. No credit card, no consultants.