How I Migrated 1,300 PCs at 18

I showed up to the North Carolina Department of Revenue in an ’89 Mazda MX-6 I bought for $1,400. I had put $2,200 worth of wheels on it. Another two grand in the stereo. Fifteen hundred in paint. The car was worth more in parts than it was as a car, which is probably a reasonable description of my priorities at 18.

I was an intern. It was supposed to be a summer thing — a connection through my high school careers coordinator who knew I’d taken a programming class and figured I might be useful. The plan was to spend a few months, go to college, move on.

That’s not what happened.

What I walked into

The Department of Revenue in 1999 was running a mixed environment — some machines still on Windows 3.11 and MS-DOS, most on Windows NT 4.0, with Novell NetWare handling identity management and file access across 30 offices statewide. Over 1,300 users. A real enterprise environment, by any measure.

The way they built new machines or fixed broken ones was the way everyone did it then — by hand. You’d pull the machine, bring it to the server room, format the disk, install the OS, layer the software on top, one application at a time. A full afternoon for a single machine, if everything went well. Longer if it didn’t.

I watched this happen a few times and thought: there has to be a better way.

There was.

The imaging problem

Using Norton Ghost for imaging and Novell ZenWorks for software distribution, I built a system that could deploy a fully configured workstation — OS, applications, policies, everything — in about 15 minutes. From scratch. At the user’s desk. While they went to get a cup of coffee.

This sounds simple now. It wasn’t simple then. Images in that era were largely hardware-dependent, which meant maintaining separate images for each specific machine configuration in the environment. It required a lot of scripting, a lot of testing, and — I will admit this freely — a lot of trial and error.

More than once I left a boot disk in my own machine, rebooted, and watched my hard drive get wiped clean by my own automation. That’s how I learned that the system needed confirmation steps before doing anything irreversible. Not from a textbook. From destroying my own work, repeatedly, until I built in the safeguards myself.

Those safeguards became the standard.

When the team saw what I’d built — a deployment process that took an afternoon down to 15 minutes, repeatable, documented, runnable by anyone — they didn’t send me back to my intern desk. They said: let’s use this to migrate the whole organization to Windows 2000.

I was 18. I said yes.

The part nobody planned for

My freshman year at North Carolina A&T, my mother had a stroke.

She made a full recovery. But I moved back to Raleigh, and the plan to just be a college student got complicated fast. I transferred credits, restructured everything, and ended up commuting — Greensboro on Tuesdays and Thursdays for a 14-hour course load, Raleigh on Mondays, Wednesdays, and Fridays for the job.

Eventually I transferred to NC State to close the distance. My schedule there: class 8 to 8:50am, work 9 to 5:30pm, class again 6 to 9pm.

I’m not telling you this for sympathy. I’m telling you because it’s the context for everything else in this story. The migration planning, the site visits, the documentation — all of it happened inside that schedule. You figure out how to be efficient when inefficiency isn’t an option.

Statewide, in an MX-6

Thirty offices. Raleigh, the coast, the mountains, everything in between. The deployment required physical presence — you couldn’t push a Windows 2000 migration remotely in 2000, not at this scale, not with this infrastructure.

So I drove.

I scheduled site visits around my class schedule. Offices close to Greensboro got done between classes. Offices back east got full work days. Larger locations — 30, 40, 50 machines — took multiple days and required staying overnight. Smaller ones, five or ten machines, were done in a couple hours and I was back on the road.

I would pull up to a state government office in the MX-6 — wheels, stereo, the whole thing — walk in with equipment, and introduce myself as the IT guy. The looks I got were a specific kind of look. The “you’re the IT guy” look. The one where someone is clearly doing math about how old I am and whether they should be concerned.

I let the work answer that question.

At the larger offices there were Network Managers who handled server configuration — my job on the server side was logistics, plug and play, getting the right hardware in the right place. The workstation migration was mine. I ran the imaging process, worked through the deployment checklist, made sure every machine came up clean before I left.

Then I got back in the MX-6 and drove to the next one.

What it taught me

I learned to see problems as invitations. The imaging process was broken, so I fixed it. The fix turned into a methodology. The methodology turned into a statewide deployment. None of that was planned — it started because I was impatient and didn’t want to spend an afternoon dragging machines to a server room.

Impatience, aimed at the right problems, is a legitimate professional skill.

I also learned that credibility isn’t conferred. Nobody gave me that project because of my résumé or my degree. They gave it to me because I solved a problem they hadn’t asked me to solve, documented it well enough that anyone could run it, and proved it worked before I proposed scaling it. The authority came from the work.

That’s still how I operate. Walk in, find the thing that’s broken or inefficient or quietly costing someone money, fix it, show your work. The rest takes care of itself.