Peachy Adventure Operations systems, built by hand. Jonathan Phillips

Preserves No. 1 Transitions

Closing to go-live: 28 days to next day

Ingredients
one checklist, four rebuilds, about 1,500 tasks, no heroics
Packed
Summer 2025 to Fall 2026
Best before
the next threshold of scale

When I started there was no written transition process, and there was one of me. The company was buying faster than one person could hand-hold: 24 sites across 14 closings in sixteen months. The first closing on my watch took 28 days from closing to a live property system, and a transition then meant about six days on site.

I wrote the process down on day 13 and rebuilt it every time the company outgrew it: a checklist, then a four-phase plan, then a task system, then an engine that generates a whole transition, about 200 tasks a site from 213 templates, routed to owners through a roster. In August 2026 four sites closed on one day and were live on the property system the next. On-site time is down to about a day and a quarter per site, and my share of the tasks fell from all of them to 27%. It runs without me in the middle, which was the point.

Open the jar

The mess

I joined a self-storage owner-operator in May 2025 as its second hire. Two weeks before my first day the company had closed on five sites at once, and their transition became my first job; three weeks after, it closed another. Counting those five, I have integrated 24 sites across 14 closings in sixteen months. A transition is everything between the seller handing over the keys and the property running on our systems: tenant records out of the seller’s software, or off paper; stored payments moved so autopay doesn’t start over; locks and keypads recoded; cameras up; utilities, insurance and vendors switched; tenants told what changes and what doesn’t; the office closed and the site run from ours.

There was no written process, because nobody had needed one yet. The first closing on my watch took 28 days from closing to a live property system. I was on site for four days with the tenant files in paper folders, and I was also the entire transition team.

What I built

In batches, each one for the size we were and the size after it.

  1. Day 13

    I wrote down what I had just done as a standard operating procedure, so the next one would not start from a blank page. Ugly, and the most useful document I wrote that year.

  2. August 2025

    A four-phase checklist, from 60 days before closing to two weeks after, plus a settings guide for the property system and a transition Q&A. A month later, a knowledge repository with one folder per property, which every transition since has used.

  3. October 2025

    The checklist became a task system: an owner and a due date per task, and an “applicable” column, because not every site needs every step. I estimated a transition at about 333 hours of work, eight weeks of one person, and designed the system to spread it. The worksheet went through five versions.

  4. August 2026

    Four sites closing on the same day. I turned the worksheet into a template base that generates the whole transition: 901 tasks in about three minutes, with a dashboard beside them. That base became the template for every transition since: 213 templates, about 1,500 real tasks generated so far, about 200 per site.

  5. September 2026

    Owner routing through a roster, so a coordinator assigns the work, and an operations handbook whose stated purpose is that nobody has to ask me where a piece of work goes.

The call

It’s almost impossible to build something for 10 properties that’s going to scale to 1,000 perfectly. So I stopped trying. Each version was built for where we were and the next threshold, and I let it get outgrown on purpose. A rebuild at every threshold is cheaper than a perfect system too early, and much cheaper than no system. The second call: hand it off before it’s finished. The roster and the handbook exist so that a coordinator can run a transition I’ve never seen.

Seconds from this batch

The first closing on my watch took 28 days and most of a week on site, and I’d do it the same way again: you can’t write the checklist before you’ve done the thing once. The hours per transition were never measured, only estimated, so “eight weeks of my time” against “four weeks across a team” is my estimate against my estimate; say so if you quote it. And I waited too long to write things down. Day-one advice to myself: write it down sooner.

Still mine

27% of the tracked tasks. What’s left is work that needs intimate knowledge of a particular deal, or hasn’t hurt enough yet to be worth automating, or doesn’t have the volume to justify a hire. Each piece leaves my plate when it crosses one of those three thresholds.

What transfers

Write the first version the day after you do the thing once; not before, and not a month later. Build each version for the size you are and the size after that, and plan to throw it away. Put every task, its owner and its due date in one place everyone can see; the tool matters less than the fact that it is one place. And measure the two things that are cheap to measure, days from closing to live and days on site, from the first one, because you will never go back and reconstruct the hours.

Bring me one like this

Buying something, or merging two things, and need it running the next morning with the office closed?

Pull over.

pullover@peachyadventure.com