An Example Migration Plan & Architecture for Game Studio Archival Domains


Ride” by Tommee Profitt, Jung Youth 🎵

I’ve been working on another blog post about how AWS released the CSI driver for Amazon FSx for OpenZFS for Kubernetes and how excited I am – it’s critical for build farm workloads. I also wrote the story about the time I accidentally met Kevin Miller, the former VP for S3 at a rave and talked his ear off about large objects. I’m embarrassed about that so I won’t be sharing it this week. Maybe I’ll get the courage next week to talk about both.

In any case, when I talk to mentees I realize infrastructure can seem like an impossible domain (get it?) to get hired into. I get why – there’s examples of architectures out there, but there’s not a lot of examples of what managers are looking for. I think the biggest shocker often is “Wait! I have to write? Not just code?” Yup.

We Both Need The Plan

This weekend I realized I had to get a migration and decommission plan out of my head and that was an opportunity to sit in “both chairs” again if you will – as someone who needs to approve the plan and someone who needs to make sure they understand how they want to execute the plan.

You see. I’ve kept live even though all the games Ker-Chunk Games LLC managed are now sunset. I work at Zynga and I love it – all my energy goes there. This business was officially closed down so my only passion is to respect the developers, artists, business, legal, writers and creators who used to work with me at Ker-Chunk Games and try to keep the credits I can live as a record that, yes, we did indeed make some really complicated games and women really did work on them. That said, in April the IGDA shared that the situation for, well, crediting people who worked on games is still pretty terrible.

Knowing that so many of the games I worked on before 2017 did not have my name in them, it’s been somewhat of a personal mission (and perhaps one could argue nightmare) for me to try to keep those credits live. But it costs. I’m still getting billed. Billed more than I’d like and there’s still entropy. Which I hate. I’ve written about entropy before and how awful it is also in relation to credits and shutting down games but with regards to the Facebook SDK.

I’ve had a full decommission and archival plan living in my brain for about 3 months that now I must execute because this business shouldn’t have anything left. For the games it doesn’t, but there’s still little tidbits everywhere. Also if you’ve ever run a business then you know – that if you let domains just expire you actually can end up in a situations with bad actors – I try to hold on to domains for a little bit through that. Given that’s the case I decided to share it publicly so students can learn from its structure and generally how I think about archiving, credits, and a process for taking something like a business and what comes after – of which, there is very little record and no instruction. I wished so much that there was someone to hold my hand through this, but there just isn’t. Womp womp. At least I can hold yours.

This plan is what I’m looking for when others migrate – requirements, timeline, steps for safety and testing, and how you’re going to do it.

You can read the migration plan here | You can download the architecture here

Every company does migrations, planning, and winding down differently but I’ve always had a written plan or design whenever I’ve tackled anything. There’s 3 reasons for this – If I sit down and draw it out, I feel a lot more confident when I do it. The other is to teach others. And the final is – If I don’t write and don’t get it out of my head, then it stays there tormenting me forever.

I wrote this in 4 hours. It’s out of my head, I feel at peace, and I can go enjoy a nice glass of wine and play video games. At a future date, I agree to punish myself with this plan in the name of credits, the love I have for people I’ve worked with, and this industry. Happy July 4th.