I started a new IT role at a dealership and discovered an extremely fragile environment. The network has roughly 60 workstations and five printers, with systems ranging from Windows 8.1 to Windows 10. Some machines use Active Directory managed by an old IBM server running Windows Server 2008, while others are standalone. There are also several headless Windows file servers, a completely flat network, two DVRs instead of proper NVR infrastructure, and questionable or unlicensed Windows installations.
The most serious issue is that the dealership's main data is stored on a single 1 TB SATA hard drive in a headless Windows machine. That system hosts the Tally server, file shares, and an Apache-based site used for purchase information. The drive has no backups, no redundancy, and is accessed continuously during business hours. All systems are shut down after work each day. A FortiGate firewall sits at the internet edge, but I have not yet determined whether it is properly patched or maintained.
The previous administrator recognized many of these problems and recommended a more appropriate setup, but management sees IT as a basic expense and is reluctant to spend money. Since that administrator is leaving, I am worried that the inevitable failure will be blamed on me.
If I stay, I was considering reusing an old server, installing Proxmox, running a newer Windows Server virtual machine for Active Directory, migrating away from Server 2008, and using a Debian-based VM to consolidate the scattered file servers. I was also considering storage technologies such as mergerfs and SnapRAID. Is that a reasonable direction, or should I approach this differently?
4 Answers
Your first priority is not Proxmox, AD, VLANs, or a prettier server room—it is getting a reliable backup of the critical data. Make a full copy or image of the important systems, establish an off-site or cloud copy, and regularly test that the data can actually be restored. A backup that has never been restored is only an assumption.
After that, document the environment exactly as you found it: hardware, software versions, licensing problems, single points of failure, firewall status, dependencies, and what business functions stop when each system fails. Put the risks, recommendations, estimated costs, downtime, and recovery options in writing and send them to management. Do not make major changes to production before you have a recovery plan.
This is a serious security and operational liability, especially with unsupported systems, questionable software sources, a flat network, and no tested recovery process. The FortiGate cannot compensate for compromised endpoints or an unprotected internal network. Check its firmware, subscriptions, administrative access, configuration backups, remote-access rules, and logging, but avoid making changes blindly.
I would spend the first few weeks learning the dependencies and preserving evidence of the current state, while implementing only low-risk protections such as verified backups, endpoint protection, patching where safe, stronger administrative credentials, and restricted internet exposure. Do not unplug systems or deliberately trigger a failure to prove a point. If management will not authorize the necessary improvements, the safest career move is to leave before the failure becomes your incident.
Before committing yourself to this project, find out whether leadership is actually willing to fund it. Present the situation in business terms rather than technical jargon: one disk failure could stop sales, accounting, customer records, and daily operations; recovery could take days or fail completely. Include quotes for backups, replacement hardware, licensing, support, and data recovery. Also ask about obligations involving customer information, payment systems, and insurance requirements.
If they approve a budget and realistic timeline, this could be a worthwhile infrastructure project. If they refuse and still expect you to guarantee uptime, you are being set up as the scapegoat. Continue doing basic risk reduction, but start looking for another job and do not accept responsibility for risks that management has explicitly chosen to leave unaddressed.
Make sure any refusal is documented professionally. A short written statement of the risk, recommendation, cost, and management decision can matter a lot when someone later asks why the problem was never fixed.
The virtualization idea is technically reasonable, but it is not a solution to the management problem. Proxmox can host a modern domain controller and other services, but the host still needs enough memory, reliable storage, monitoring, backups, and replacement parts. SnapRAID is useful for certain archival workloads, but it should not be treated as a substitute for backups or a high-availability design. For active databases and business-critical files, use storage designed for the workload and maintain multiple independent copies.
A sensible long-term plan would include replacing unsupported operating systems, licensing the software properly, separating networks with VLANs and firewall rules, removing unnecessary services from the database machine, creating redundant identity services, and moving suitable workloads to supported cloud or SaaS platforms. Do not migrate everything at once; stabilize and protect the data first, then modernize in controlled stages.
I would be especially careful about placing all the recovery work on the same old hardware. If possible, create a separate backup target and verify the data independently before attempting migrations.