Every IT engagement starts the same way: the previous setup was underdocumented, some configuration exists only in someone’s memory, and nobody is quite sure what all the moving parts are. I’ve seen this at every scale — from 10-person startups to organizations running hundreds of endpoints — and the pattern is remarkably consistent.
The difference between an IT environment that can be managed effectively and one that’s a constant source of surprises is documentation. But that documentation has to be created deliberately, during onboarding, before problems surface. What follows is the process we run at the start of every engagement, and the sections that most IT transitions skip.
Network Topology First
Before you can manage anything, you need to understand the physical and logical network. This sounds obvious and is consistently skipped in favor of jumping straight to the helpdesk tickets.
Network discovery should produce:
- A complete inventory of every network device: switches, routers, firewalls, access points, with make/model, firmware version, and management IP
- A network diagram showing VLAN segmentation, uplinks, and WAN connections
- A list of static IP assignments and the DHCP scope
- Documentation of DNS zones, internal and external
- The current firewall ruleset, exported and stored securely
This takes time. For a typical 50-user environment, expect two to four hours of active discovery plus time to document findings. For a 200-user multi-site environment, it’s a multiple-day effort. Don’t let anyone compress this timeline.
Credential Vault Setup
The first task on any IT takeover: move all credentials into a password manager. Not a shared spreadsheet. Not a Google Doc. A proper credential vault with audit logging, role-based access, and MFA.
Every credential that currently lives in someone’s head, someone’s personal password manager, or a sticky note needs to move to the vault during onboarding. This includes:
- Domain admin credentials
- Firewall and network device admin passwords
- Cloud provider root/admin accounts (AWS, GCP, Azure)
- Email admin accounts (365, Google Workspace)
- ISP portal credentials
- Backup system credentials
- Any SaaS admin accounts the business relies on
The vendor-specific “break glass” accounts — the emergency credentials used when everything else fails — need to be documented, stored securely, and tested. The worst time to discover that the emergency firewall credential doesn’t work is during an outage.
Software and License Inventory
This step gets skipped because it’s unglamorous and time-consuming. It matters enormously when something breaks.
A complete software inventory should include:
- Every installed application on every managed endpoint
- License counts and expiration dates
- Who holds the license account credentials
- Any software running on servers that’s not covered by the endpoint inventory
The license expiration piece is where businesses get surprised. A certificate that expired three years ago. An antivirus license that lapsed and nobody noticed the software stopped updating. A support contract that lapsed right before you needed it.
Build a calendar of renewal dates as part of onboarding. Flag anything expiring within 90 days. Review the list quarterly.
Backup Configuration Audit
I want to be direct about this: most small and mid-size business backup configurations are not adequate. When we audit backup setups during onboarding, we commonly find:
- Backups running to a device on the same network segment as the systems being protected (so ransomware hits both)
- Backup jobs that have been silently failing for months
- No documented restore procedure
- Backups of the operating system but not the application data
- Retention policies too short to recover from a slow-moving failure
The backup audit produces three things: the current backup configuration in writing, a list of gaps, and a restore test. The restore test is mandatory. Run a restore of a representative dataset and document how long it took and whether the data was complete.
If the restore fails, you’ve found the problem now instead of during a crisis. Document the failure, fix the configuration, run the restore again.
Active Directory / Identity Audit
For any organization using Active Directory or Entra ID (formerly Azure AD), the identity audit is where skeletons live. Common findings:
- Former employee accounts that are still active
- Service accounts with interactive login privileges and no documentation of what they’re used for
- Admin accounts shared across multiple people
- No MFA on admin accounts
- Password policies set to the Windows 2003-era defaults
Disable former employee accounts immediately. Document every service account: what runs with its credentials, where it’s configured, and what breaks if the password changes. Require MFA on all admin accounts before the end of the first week.
This isn’t IT hygiene for its own sake — it’s a security baseline that matters. An active account for an employee who left two years ago is a credential that exists with no one watching it.
Vendor Relationship Mapping
Every business has vendor relationships that IT owns or intersects with. These need to be documented centrally:
- ISP: account number, support contact, contract expiration, current bandwidth tier
- Hardware warranties: which devices are under warranty, what the support tier is, and how to open a case
- Software vendors: contract terms, renewal contacts
- Specialty vendors: the VoIP provider, the copier company, the building access control system
This documentation prevents the scenario where your ISP support call requires a 30-minute wait on hold to verify account information that nobody wrote down.
Monitoring Baseline
Once the environment is understood, configure monitoring against it. The monitoring configuration should reflect the specific environment, not a generic template.
Every server and network device should have:
- Uptime/availability monitoring with appropriate alert thresholds
- Disk usage monitoring with trend-based alerting (not just “alert at 90%”)
- CPU and memory baseline with alerting for sustained anomalies
- Certificate expiration monitoring for any public-facing HTTPS services
- Backup job success/failure monitoring
The first two weeks of monitoring will surface a list of things that need fixing. Prioritize them and work through them systematically. The monitoring environment at the end of a proper onboarding should be quiet — not because alerts aren’t working, but because the environment is clean.
The Documentation That Survives Personnel Changes
The final output of a proper IT onboarding is a runbook: a document that captures enough operational knowledge that a competent IT person who’s never seen the environment before can keep things running.
The runbook isn’t a wall of text. It’s a structured set of procedures: how to add a new user, how to reset a password, how to respond to specific alerts, how to restore from backup, who to call for which vendor.
This document lives in a system that survives the departure of any individual — not in someone’s email drafts, not in their personal Notion. It’s reviewed and updated quarterly. When procedures change, the runbook changes.
Our managed IT services engagement starts with this full onboarding audit before we take operational responsibility. It typically takes 2-4 weeks for a 50-100 user environment. Some clients are surprised by the time investment. None of them are surprised after the first time we catch and resolve a problem that the previous setup would have turned into an incident.
If you’re evaluating managed IT providers, ask them to walk you through their onboarding process. The specificity of the answer will tell you a great deal about what working with them will actually be like.