Inherited My First It Department Where Would You Start

Posted Aug 1, 2026

By Usman Masood Ashraf

views 8 min read

Inherited My First IT Department: Where Would You Start

Introduction

Stepping into a brand‑new IT role within a small municipality can feel like being handed the keys to a massive, partially dismantled machine. You inherit a stack of legacy configurations, scattered documentation, and a handful of passwords scribbled on a sticky note. The previous external Managed Service Provider (MSP) walked away because the city’s growth outpaced their capacity, leaving you as the first internal IT manager with a clear mandate: bring order to chaos, establish reliable infrastructure, and lay the groundwork for sustainable automation.

For homelab enthusiasts, self‑hosted practitioners, and DevOps engineers, this scenario is a familiar crossroads. Whether you’re managing a 150‑person municipality or a personal lab of 150 containers, the core challenges — inventory, baseline stabilization, automation, and security — remain identical. This guide walks you through a pragmatic, step‑by‑step approach to “where would you start” when you inherit an IT department that has been operating in a quasi‑MSP mode.

You will learn:

How to conduct a rapid yet thorough assessment of the existing environment.
Which open‑source tools and proven frameworks can replace fragmented MSP processes.
The exact prerequisites, installation steps, and configuration patterns needed to bring the infrastructure under version‑controlled, repeatable management.
Practical examples of Docker‑based deployments that avoid Jekyll‑sensitive syntax, using placeholder variables such as $CONTAINER_ID and $CONTAINER_STATUS.
Strategies for ongoing operations, monitoring, backup, and troubleshooting that keep the system resilient.

By the end of this 3,500‑word guide, you’ll have a clear roadmap that transforms a chaotic hand‑off into a structured, auditable, and scalable IT operation — ready for the next phase of growth.

Understanding the Topic

What Does “Inheriting an IT Department” Actually Mean?

When an MSP exits a municipal contract, they typically leave behind a patchwork of services:

Network infrastructure – routers, switches, and firewalls configured via ad‑hoc scripts.
Ticketing and asset management – spreadsheets or legacy tools with incomplete data.
Server and service hosting – a mix of physical boxes and virtual machines running outdated OS versions.
Security controls – weak password policies, undocumented privileged accounts, and minimal logging.

The core challenge is not merely to “fix” these components, but to establish a repeatable process that captures the current state, validates it, and then migrates it into a controlled, version‑controlled environment.

Historical Context of Municipal IT Management

Municipalities traditionally relied on external vendors because internal expertise was scarce and budgets limited. The MSP model worked for small populations but broke down as services expanded — more users, more applications, and stricter compliance requirements. The resulting technical debt manifested as:

Manual configuration changes that could not be rolled back.
Inconsistent patching cycles leading to security exposures.
Lack of centralized monitoring, causing outages to go unnoticed for hours.

Modern self‑hosted and DevOps practices provide the antidote: infrastructure as code (IaC), containerized services, and automated compliance checks.

Key Features of a Modern, Self‑Hosted IT Stack

Feature	Why It Matters	Typical Open‑Source Options
Configuration Management	Ensures consistent state across all nodes	Ansible, SaltStack, Puppet
Service Discovery & Monitoring	Detects outages before they impact citizens	Prometheus + Alertmanager, LibreNMS
Ticketing & Asset Management	Provides a single source of truth for incidents and assets	Odoo, Request Tracker, NetBox
Container Orchestration	Enables scalable, isolated deployment of services	Docker Swarm, Kubernetes (lightweight)
Backup & Disaster Recovery	Guarantees data integrity and rapid restoration	Duplicity, Restic, Velero
Security Hardening	Meets regulatory standards and protects citizen data	OpenSCAP, Lynis

These components form the backbone of a homelab‑grade environment that can be scaled to a municipal level with minimal friction.

Pros and Cons of a Self‑Hosted Approach

Pros

Full control over data, compliance, and vendor lock‑in.
Ability to tailor tooling to specific municipal workflows.
Cost‑effective when leveraging open‑source solutions at scale.

Cons

Initial investment in skill development and tooling.
Requires disciplined documentation and process enforcement.
Responsibility for security patches and updates rests entirely on you.

Understanding these trade‑offs helps you prioritize which area to tackle first — often the asset inventory and documentation phase, because it underpins every subsequent automation effort.

Current State and Future Trends

The industry is moving toward GitOps — treating declarative infrastructure as code stored in version‑controlled repositories. This trend aligns perfectly with municipal needs: auditability, rollback capability, and collaborative development.

Emerging practices include:

Immutable infrastructure – replace rather than patch servers.
Zero‑trust networking – micro‑segmentation for internal services.
AI‑assisted anomaly detection – leveraging Prometheus metrics for predictive alerts.

By adopting these trends early, you position the department not just as a reactive fixer, but as a forward‑thinking governance body.

Prerequisites

Before you can begin any installation or configuration, you must satisfy a set of baseline requirements. These ensure that the tools you deploy will run reliably and that you can maintain them without unexpected roadblocks.

System Requirements

Component	Minimum Specification	Recommended Specification
CPU	2 cores	4 cores (modern Xeon or AMD EPYC)
RAM	4 GB	16 GB (allows multiple containers to run concurrently)
Storage	50 GB SSD	250 GB SSD (for logs, backups, and container images)
Network	1 Gbps Ethernet	10 Gbps NIC (for high‑throughput monitoring)
OS	Ubuntu 20.04 LTS or Debian 11	Ubuntu 22.04 LTS (latest LTS)

Required Software

Docker Engine – version 24.x or later.
Docker Compose – version 2.20 or later.
Git – for version‑controlled configuration storage.
Ansible – version 2.15 or later (optional but recommended for provisioning).
Prometheus – for metric collection (optional).

Network and Security Considerations

Firewall Rules – restrict SSH access to a management subnet; only allow inbound traffic on ports 22 (SSH) and 80/443 (web UI) from trusted sources.
TLS Termination – use Let’s Encrypt certificates for any publicly exposed services.
Privilege Separation – run containers under non‑root users where possible; use Docker’s --user flag to enforce this.

User Permissions

Create a dedicated system user itadmin with sudo privileges limited to Docker commands (docker group).
Ensure that all automation scripts are owned by itadmin and have restrictive permissions (chmod 750).

Pre‑Installation Checklist

Verify OS version and apply latest security updates (apt update && apt upgrade -y).
Install Docker Engine and add the current user to the docker group.
Confirm Docker daemon is running (systemctl status docker).
Clone the central configuration repository (e.g., git clone https://github.com/yourorg/it-config.git).
Validate network connectivity to any upstream services (e.g., DNS, external APIs).

Only after completing this checklist should you proceed to the installation phase.

Installation & Setup

The following sections detail the step‑by‑step deployment of a minimal yet production‑ready stack. All Docker commands use placeholder variables ($CONTAINER_ID, $CONTAINER_STATUS, etc.) to stay compatible with Jekyll’s Liquid templating engine.

1. Deploying a Centralized Monitoring Stack

A lightweight Prometheus‑Grafana stack provides immediate visibility into container health, network traffic, and service latency.

1.1 Create a Docker Compose File

  
version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: $CONTAINER_NAMES-prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"
    environment:
      - LOG_LEVEL=info
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9090/-/healthy"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  grafana:
    image: grafana/grafana:latest
    container_name: $CONTAINER_NAMES-grafana
    restart: unless-stopped
    depends_on:
      - prometheus
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=StrongPassw0rd!
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/api/health"]
      interval: 30s
      timeout: 10s
      retries: 3

volumes:
  prometheus_data:
  grafana_data:

1.2 Deploy the Stack

docker compose up -d

1.3 Verify Container Status

  
docker ps --filter "name=$CONTAINER_NAMES" --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"

You should see output similar to:

NAMES                     STATUS          IMAGE
prometheus-prometheus   Up 5 seconds    prom/prometheus:latest
grafana-grafana          Up 4 seconds    grafana/grafana:latest

1.4 Initial Access

Navigate to http://<host-ip>:9090 for Prometheus UI.
Navigate to http://<host-ip>:3000 for Grafana UI; log in with admin / StrongPassw0rd!.

1.5 Common Pitfalls

Symptom	Likely Cause	Fix
Container repeatedly restarts	Missing volume directory permissions	`chown -R 1000:1000 /path/to/prometheus_data`
Health check fails	Prometheus not exposing `//-/healthy` endpoint	Ensure `prometheus.yml` includes `global: { scrape_interval: 15s }` and that the service is reachable
Port conflict	Another service already bound to 9090	Stop the conflicting service or change the host port mapping (`"9090:9090"` → `"9191:9090"`)

2. Setting Up a Ticketing & Asset Management System

For municipal IT, a lightweight ticketing platform combined with asset inventory is essential. Odoo Community Edition provides both out‑of‑the‑box, and its Docker image can be deployed with minimal configuration.

2.1 Pull the Odoo Image

docker pull odoo:16.0

2.2 Create a Compose Overlay for Odoo

  
version: '3.8'

services:
  odoo:
    image: odoo:16.0
    container_name: $CONTAINER_NAMES-odoo
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8069:8069"
    environment:
      - ODOO_RC=/etc/odoo/odoo.conf
    volumes:
      - odoo_data:/var/lib/odoo
      - ./odoo.conf:/etc/odoo/odoo.conf:ro
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8069/web"]
      interval: 30s
      timeout: 10s
      retries: 3

  db:
    image: postgres:15
    container_name: $CONTAINER_NAMES-odoo-db
    restart: unless-stopped
    environment:
      - POSTGRES

Open Source, Reddit Guides, Kubernetes

This post is licensed under CC BY 4.0 by the author.