Key Points
Performing Manual Tech Stack Reviews Without Audit Software
- Define Tech Stack Categories: Organize tools into core groups to ensure complete coverage and easier analysis.
- Collect Data From Existing Sources: Use RMM/PSA exports, SaaS vendor portals, invoices, and client interviews to build a complete dataset even without audit software.
- Normalize and Standardize Data: Clean vendor names, merge duplicates, categorize tools, and mark usage status to create a master tech stack inventory.
- Assess Redundancy, Risk, and Value: Identify overlapping tools, highlight unsupported or legacy systems, expose shadow IT, and align license spend with actual usage.
- Create a Client-Facing Report: Translate findings into business terms and provide actionable recommendations for consolidation or upgrades.
As businesses grow, so do their technology environments. However, these can easily get out of control as they layer new tools, services, and solutions over legacy systems, leading to redundant software, rising costs, and various security risks. Dedicated audit platforms can help manage these environments, but many MSPs and smaller organizations do not have such tools.
If you’re one of them, you can still do a manual tech stack review to deliver clear insights and actionable recommendations. Keep reading for a practical framework to help you perform a thorough, manual review of your clients’ tech stacks.
How to manually review a client’s tech stack without specialized software
A tech stack audit without specialized auditing software can be complex, but with the right structure, it can be practical and highly effective. Your ultimate goal is to clearly categorize scattered collections of tools, licenses, and systems and apply a consistent evaluation process to find redundancies, highlight risks, and consolidate or improve things as needed. Follow the steps below.
📌 Prerequisites:
- Exports from existing RMM or PSA tools, including reports on hardware, software, licenses, and patch compliance
- Access to vendor portals for SaaS license counts and billing statements
- Client input on business-critical workflows and dependencies
- A standardized review template in Excel, Google Sheets, or NinjaOne Docs
Step 1: Define review categories
The first step is establishing a clear framework for categorization to make it easier to identify and duplicate entries and risks. Doing this will ensure you can analyze the entire tech environment for your IT audit. Break down your client stack into the following core categories:
| Category | What it covers |
| Endpoint and device management |
|
| Infrastructure |
|
| Applications and SaaS |
|
| Security | |
| Backup and recovery |
|
| Compliance and policy |
Deliverable: A standardized review template with predefined categories that captures every element of the client’s tech stack to ensure no area is missed
Step 2: Collect data from existing sources
Next, gather the raw information that will fill your inventory. You’ll combine exports, vendor reports, and stakeholder insights for a more accurate assessment.
Here are some key data sources to leverage:
- RMM or PSA exports
- Export hardware and software inventories, license usage, and patch compliance data from your RMM or PSA platform.
- Look for device counts, installed applications, OS versions, and update statuses to establish the baseline of what exists in the environment.
- Vendor portals
- Access SaaS provider dashboards (for example, Microsoft 365, Google Workspace, Salesforce, or industry apps).
- To help identify underutilized subscriptions and costs tied to unused accounts, pull reports on:
- Active vs. assigned licenses
- Usage metrics (such as how many employees are actively using the tool)
- Billing and renewal cycles
- Invoices and subscription records
- Collect client billing statements for third-party tools and managed services.
- Use these financial records to align spending with actual adoption and usage, which is especially useful for uncovering hidden costs in tools not tracked by RMMs.
- Stakeholder interviews
- Speak with department heads, team leads, and end users to identify tools not captured in official systems (shadow IT).
- Ask which tools are essential for their workflows and which are rarely used.
- Interviews reveal context behind adoption (for example, “We pay for Slack, but most teams use Teams”).
Deliverable: A consolidated dataset of the client’s technology assets, combining RMM or PSA exports, vendor data, financial records, and stakeholder input
Step 3: Normalize and organize the data
With the necessary data gathered, you can make sense of everything by structuring the information for easier analysis. Normalization involves cleaning data from different sources with inconsistent formats, mismatched vendor names, duplicate entries, and vague usage notes.
To do this, consider doing the following tasks:
- Standardize vendor names and categories:
- Unify naming conventions across sources (like “MS Office 365,” “Microsoft 365,” and “O365” should all be labeled Microsoft 365).
- Apply the review categories defined in Step 1 to each tool so all entries fall into a consistent structure.
- Consolidate duplicate or fragmented records:
- Merge overlapping exports (for example, RMM shows “Zoom” and billing shows “Zoom Pro”. Treat them as the same tool with usage or licensing details combined.)
- Clean up duplicate entries caused by multiple data sources reporting the same system.
- Define usage status:
- Mark each tool as:
- Actively used: Core to business workflows
- Partially used: Limited adoption or only by specific teams
- Unused or inactive: Paid for but not meaningfully used
- Use stakeholder interviews and portal data (such as license activity) to validate usage.
- Mark each tool as:
- Capture licensing models:
- Record the type of licensing for each tool: per user, per device, per month, or perpetual.
- Note renewal cycles and whether licenses are bundled with other services.
- Document dependencies and integrations:
- Identify systems that feed into others (for example, Salesforce > Marketing Automation).
- Highlight if removing or consolidating one tool will impact other workflows.
Deliverable: A normalized, master tech stack spreadsheet where all client systems are categorized, standardized, and assigned usage status
Step 4: Assess redundancy, risk, and value
You can now evaluate each tool according to necessity, overlap, and potential risk. You’ll determine which systems deliver real value, which ones duplicate functionality, and which may expose the client to unnecessary costs or vulnerabilities.
- Identify redundancy:
- Look for tools that serve the same purpose (for example, Slack, Teams, and Zoom all used for messaging or calls).
- Highlight opportunities to consolidate platforms to reduce complexity and cost.
- Pay special attention to partially used tools that were purchased but never fully adopted.
- Evaluate risk:
- Legacy or unsupported systems: Note end-of-life tools, out of vendor support, or no longer receiving updates.
- Shadow IT: Flag any applications adopted without IT oversight, as they often lack proper security or compliance controls.
- Single points of failure: Identify tools critical to workflows that lack backup solutions.
- Assess business value:
- Link each tool to business-critical workflows gathered during stakeholder interviews.
- Determine if the tool provides measurable ROI (productivity gains, compliance, cost savings) or if it’s redundant overhead.
- Classify tools by priority (critical, important, or optional).
- Financial alignment:
- Compare license spend against actual usage.
- Identify unused licenses that can be canceled.
- Highlight where consolidating multiple tools could cut subscription or support costs.
Deliverable: A structured risk and redundancy analysis that highlights overlapping tools, legacy risks, cost inefficiencies, and gaps in coverage, prioritized by business impact
Step 5: Create a client-facing review report
Lastly, you should turn technical findings into a clear report that clients can understand. This step is crucial in delivering real business impact, as decision-makers can finally act on any concerning insights and immediately start optimization.
Make sure to do the following:
- Summarize key findings in business terms. Use simple language that focuses on cost, productivity, and compliance. For example:
- “$X per month wasted on unused licenses.”
- “Three collaboration tools performing the same function.”
- “Two unsupported systems creating a security risk.”
- Provide remediation recommendations. For each identified issue, include a recommended action:
- Consolidation: Retire redundant tools in favor of a single platform.
- Upgrades or migrations: Replace unsupported or legacy systems.
- New tools: Fill identified gaps (for example, MFA, SaaS backup, compliance enforcement).
- Visualize the findings. Use charts, summary tables, or scorecards to make risks and costs easy to digest.
- Integrate the report into client conversations. Present it during Quarterly Business Reviews (QBRs) or strategic planning sessions to guide budgeting, roadmap planning, and contract renewals.
Deliverable: A polished, client-facing tech stack review report that summarizes redundancies, risks, and costs while providing actionable recommendations
Summary of steps
Here’s a quick rundown of all the steps alongside their purpose and value.
| Component | Purpose and value |
| Defined categories | Ensures no area of the stack is overlooked and creates a repeatable review structure |
| Data collection | Leverages existing RMM or PSA exports, vendor portals, and interviews to avoid tool sprawl |
| Normalization | Standardizes naming and formats to make findings clear, comparable, and actionable |
| Risk or redundancy analysis | Highlights overlapping tools, cost inefficiencies, and security or compliance risks |
| Client-facing report | Translates technical findings into business insights that build trust and drive decisions |
Automation touchpoint example
Even when doing the review manually, you can still automate small parts of the process to save time and reduce human error using simple scripts or commands. Here’s a sample PowerShell script that automates the export of installed applications on a Windows device:
Get-Package |
Select-Object Name, Version, ProviderName |
Export-Csv “InstalledApps.csv” -NoTypeInformation
⚠️ Important: This script runs on Windows systems using PowerShell. It does not require administrator privileges, but elevated permissions may return a more complete list of installed software.
The command retrieves installed package information using PowerShell’s package management providers and exports key details (e.g., package name, version, provider) to a CSV file named “InstalledApps.csv.” The resulting file can be opened in Excel or imported into other tools to create a baseline inventory of installed software. This script is useful during the data collection phase, providing a quick baseline of installed applications across a system without the need for specialized audit software.
NinjaOne integration
NinjaOne fits nicely into a manual IT review process, with capabilities that can help with data collection, organization, and presentation.
| NinjaOne capability | How it supports the review |
| Inventory exports | Export hardware and software data directly from NinjaOne to seed your review process |
| Docs integration | Host master tech stack inventories, review templates, and client-facing reports in NinjaOne Docs for easy access |
| Automated reminders | Set quarterly or annual review reminders to ensure the process is consistent and repeatable |
| Application tagging | Tag redundant or non-standard applications across client environments to quickly identify overlaps |
| QBR dashboard linkage | Integrate review findings into client-facing QBR dashboards to align technical insights with business discussions |
Optimizing tech stacks without extra tools
A manual tech stack review might not be as quick and efficient as dedicated stack audit software, but it can offer just as valuable outcomes if you structure it properly. With the listed steps, MSPs can uncover hidden inefficiencies and make necessary changes to align IT resources with their business goals.
Related topics:
- Building the Right MSP Software Stack: 3 Key Evaluation Criteria to Make Sure You Don’t End Up with the Wrong Tools
- What Is Full Stack Observability & Why Is It Important?
- How to Audit Your MSP Tool Stack for Overlap, Waste, and Underutilization
- A Step-by-Step Guide to Creating an AI Stack for IT Operations
