Episode 21: Migrate and Populate the Content (w/ Carrie Hane)

Hello, this is the Web Project Guide podcast and this is episode 21, migrate and populate the content. I'm Corey Vilhauer, director of Strategy at Blend Interactive and co-author of the Web Project Guide. Later we'll be joined by Carrie Hane, co-author of Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow. But first, I'm joined by my co migrator Deane Barker. Deane, Hey, what do you know about migrations? Have you ever talked about migrations before, Deane?

You just called me a co-migrator.

I don't know. I got to struggle sometimes with these.

Weirdly, I actually talk about migrations quite a bit. It's a topic that comes a lot when you're selling people software. Because they always want to talk about migration. When it was at Blend, migrations would come up all the time. I actually do talk about migrations a lot. I actually have a college lecture that I do specifically on migration, I've done some webinars on it. I weirdly enjoy it. But to be clear, this is a crappy topic that nobody ever wants to talk about. When we got in touch with Carrie, who's lovely and said, "Hey, do you want to come on the podcast?" And she was probably like, "Yeah, that sounds great." And then we said we were going to talk about migrations and she was like, "Oh, okay." Because this is the thing that everybody wants to pretend Doesn't have to happen, but it does.

Yeah, I remember when you migrated Gachatopia, which was your longtime tech blog that turned into a CMS blog eventually. Walk through that process at a real high level. It was fascinating to me. You made some really interesting decisions that I think most people wouldn't make during a migration.

Yeah, so I think what you're talking about is when I kind of pruned Gachatopia. I had 7,000 posts out of Gachatopia. Like an actual migration, moving from CMS to CMS, the first thing you absolutely have to do is editorially just figure out what's moving and what's not. This can be hard because we tend to be protective and have ownership over our content. But I did a big analysis of Gachatopia comment for things like length, link viability, inbound traffic, and then what I called centrality. I thought I was breaking new ground with this, turns out I wasn't, but my posts on Gachatopia were very, very interlinked. I examined link chains between them and figured out which were central ones. I examined them for keyboards, and at the end of the day, 7,000 posts, I threw away 95% of them almost exactly.

(02:45)
The blog to this day is about 360 posts because the easiest content to migrate is content you don't actually migrate. The easiest content to migrate is content that you delete. That's probably the biggest thing you can say about a migration is you just want to make the work easier for yourself, like when you're moving house and I have no doubt that moving house will be the analogy that we talk about a lot with Carrie because it's the analogy everybody uses when you're talking about migration. The easiest thing to move is something that you throw away and when you're going to move house. When you go through the basement, you seek to throw away as much stuff as you can, which is the same truth of any migration.

(03:22)
Then once you get past that editorial question, then you have to figure out how is this content actually going to work in the new system? Then once you figure that out, then you actually have to do the work. You have to figure out bytes on disc. There are bytes on hard drive somewhere. They have to move to those bytes on a hard drive somewhere else. What does that mechanical process look like? Migration is that entire scope of work and it is never given the respect that it deserves. People wait until the last minute and procrastinate, try to pretend that it doesn't happen. Corey, you and I know about projects that had launch delays of over a year because the customer had no plan to migrate their content.

Right. This is already becoming a depressing episode, so we're going to skip most of those stories.

We've been down this road where customers weren't able to launch because there was no migration plan or there was a plan that the customer didn't follow through on, which happens quite a bit. Migration is an easy thing to plan, but a very difficult thing to execute. Many website launches have been delayed because of content concerns. This is what we're going to drag Carrie into kicking and screaming to talk to us about.

Carrie Hane works at Sanity, a content platform that focuses on treating content as data for maximum flexibility. She's also co-author of designing Connected Content: Plan and Model Digital Products for Today and Tomorrow. First, the Web Project Podcast is sponsored by Blend Interactive, a web strategy, design, and development shop dedicated to guiding teams through complicated web and content projects. Blend's been building great websites for over 18 years and we're always looking for our next partnership so visit us at Blend Interactive. All right, let's welcome our guest, Carrie Hane. Hey Carrie.

Hey Corey. Hey Dean.

Welcome to the podcast. We are going to be talking about a subject near and dear to everybody's hearts. The one thing about content management implementations that everybody loves the most and always plans for it and has an incredibly realistic view of, and that is content migration.

Definitely. I guess we're done now.

Yes.

So well-informed.

If we're going to talk about things that go right in content migrations, then this is going to be a very short podcast. My experience with content migrations, Carrie, and then I'll give you a chance to say your experience, is that customers never plan enough time, they never plan enough budget, and they tend to go into implementations thinking just assuming that there's a magic way content jumps from one system to another. Carrie, why don't you tell me what your experience has been?

My experience used to be like that, and then I started working with people who hired me to fix their content first before they started fixing their CMS, and that went much better. Yeah, I think that's the trick, is work on your content first plan that and your migration will go much smoother.

If a buddy asks you to help him move, so you bring your truck over to help him move and you show up, there's two different ways this could go. Your buddy could have everything boxed up and all ready to go in the foyer ready to go out the door. Your buddy could have done all of the pre-work already or your buddy could have done absolutely nothing and be waking up from a three-day bender and expecting you to, first we have to go get some boxes. How do you think that that sort of plays out in your experience?

I think that's a good analogy for how people and organizations approach website migration. More people are like the second guy where they aren't prepared. They just think it's all going to magically come together. It does, but it's way more painful and probably takes a lot longer than the other way.

It's like the focus is on the truck and not on the boxes. It's not on the packing part, which I guess is probably a metaphor for technology. I think whenever we talk to people at Blend about migration, I think there's a large group of people who assume it's a technology problem. Well, we know it's obviously more than that, it's both a technology problem and a content problem. I guess one of the things I was curious is how do you, as somebody who doesn't identify as you might identify as a technologist, but really you identify as an IA or a content strategist, how do those fields help inform that migration process? How do people prepare for it?

First of all, you can't separate them. Information architecture is the organization classification and naming of information. Migration is part of that, or includes those aspects. Content modeling is the process of identifying content types and their structure properties and relationships. I do that during migration. I've been doing this since ... I was thinking about this in preparation for talking to you guys, since about 2005. It's been a while. Mapping, to me, it started when I first started before we had CMS', it was mapping. "Okay, here's the old site map, here's the new site map, what do we have to do to get from A to B?" And then once the CMS' took over, it was you had to define how content needed to be transformed during the migration to fit into the CMS. I advise people to start with content modeling, define the new website IA, and not just the site map, but how it's going to be organized and classified and how you're going to get things to be curated or automatically display because that affects how you set up your CMS, which then affects your migration.

(09:48)
If you do all that early and sometimes even before you decide what CMS you're moving to, then things will go much smoother, which of course is what you all advise in your book and anyone like us will advise that. But do people listen to us? Sometimes, not always. At some point to me it becomes a math problem. You have this many pages, you need to get them over here. What needs to happen to go from here to there? Just like a road trip. You want to go from Sarasota, Florida to Seattle, Washington. You could fly, you could drive, you could take a Greyhound, you could take the train, depends how much time you want to spend, how much you want to pack, how much pain you want to endure.

Yeah.

You said something about you were doing this back in 2005. I too was doing this back in 2005 when we were both young and innocent naive children running through the forest. Do you think migration has changed fundamentally since 2005? The reason why I ask that is because back in 2005 even, that may be on the outer edge of this, but not every organization had a website. A lot of website builds were brand new, so there was nothing to migrate. Organizations that had built a website in the late 90s or the early 2000s often were completely throwing everything away because it was the first website didn't know what they were doing. Now I feel like the web is now 30 some odd years old. You have organizations that have an enormous wealth of digital content, that has work, has a track record, and so it becomes this perpetual body of work that now we have to keep moving.

(11:38)
It's like the first time you bought a house, you've been living in apartments as a 20 something. You buy a house, a lot of times you throw your crap away because it's like terrible stuff that you had in your apartments and you buy new furniture for your house and then when you move house to house to house, you're kind of moving these family heirlooms. I feel like that kind of corresponds to how migration goes now. Organizations are coming to us with a lot more content to move. Compared to the innocent days of yore, how have you seen it change?

Well, yeah, honestly it's just more volume. I think organizations still often don't know what to keep, what to get rid of. There's a lot more hoarding happening than people realize until they go to move stuff and they're like, "Oh my God, we have to move 100,000 pieces of content. Do we need to?" Maybe, maybe not. It's really just scale. I don't think it's a whole lot different. For the people who in 2005 to 2010 and '12 who had a website and were making a new one because they had learned something, if they were hoarding, it wasn't a big deal because it was still tens or dozens of pages, not thousands or tens of thousands, but it wasn't necessarily good.

(13:00)
That gets into an audit. How do you decide what to move is more in the content audit realm, but you also have to decide what transformation needs to happen. Can you just move it from here to here without really touching it? Do you need to do small little bits or do you need to completely rewrite, reformat everything? There's some of that in every migration. It's figuring out how much you need to do for each one based on budget, time, resources.

I think that the holy grail of content management that we've always been trying to work towards is some kind of unified theory of content management, some kind of unified way that people store and organize content. There've been several attempts on that in the past, but nothing has particularly stuck. Beyond the concept of having types with properties and maybe relationships, there are very, very few commonalities from one system to another. I always maintain exactly what you said. The first step is to figure out the editorial question, what's going to move? But then the next step is the functional question. Literally, how is this going to work in the new CMS?

(14:11)
I always maintain, you have a couch in your old house and you move it to your new house. Well unfortunately your new house doesn't have a wall long enough in the living room for that couch. You didn't take into account that some things just weren't going to work over there. Then after the functional question works out, then you get into the procedural question. How do we actually do this? Let's talk about a schedule. Have you worked projects that have been fundamentally migration projects with a very small development and component attached to it? This may be more of a Blend thing because we did much more technical implementation work at Blend, but I remember projects coming in where I said 80% of your budget's going to be on migration. The actual development's not that big.

Yeah, I mean when I was working for an agency back when we were starting to set up the CMS and migrating mostly from not having a CMS to a CMS, so this was like 2009 to 2012. We would tell people that, and they, "No, no, no, it won't be that much." That's where simple math comes in. It's like, you have 300 pages, they need to be moved over. It takes a certain amount per page. Or you have to pay a developer to write a script to do all these things. Guess what? Developers are your highest rate. You're paying a lot for people. It's not magic. They think it's magic. Whether you're paying a developer to write a script, test it, rewrite it, test it, rewrite it, test it, and then actually do the migration or paying an intern $10 an hour to copy and paste, it's a math problem.

Let's talk about migration disasters. What happens if there's always that dreaded kind of content freeze window where you're just about to launch. "Okay, stop working on the new site everybody." Or, "Stop working on the existing site. We're about to launch the new site." Hopefully you can get that done in 24 hours, but sometimes I've seen that'd be weeks long. Have you been in projects where migration has absolutely crashed and burned, they had to back out and start over?

I don't think so. I've blocked out most of those disasters.

I unfortunately was involved in such a project and it was my own damned fault. You have this situation any migration where you have this content freeze where you're waiting to launch the new site and you're telling people don't edit content on the existing site and you can't edit on the new site yet because it hasn't moved. You have this weird moment. I always think of, who was it? Kevin Klein in On Golden Pond where he is got one foot on the boat and one foot on the dock and they start to separate and you've got feet in different systems. I had a system where we were in a content freeze and we tried to launch the site and it kept crashing and it turns out it crashed because of the way I wrote something. We had to back it out. We had to put the new site back up and then tell all the editors, "Okay, we're going to try again next week. You can go back to editing on the existing site." They had to go back to that migration mode again.

(17:14)
This is like that situation where ... I feel like we're beating the analogy of moving houses to death, but it's very, very true. When you move houses, some of your stuff are here and some of your stuff are here. It always feels good where you get the important stuff unpacked and you feel like, "Okay, now when I think about going home, I'm thinking about the new place, not the old place." But I have had absolute disaster, something David Hobb calls migration train wrecks. What do you do in a situation like that, just back off and plan it out again later? How do you pick up those pieces?

Yeah, I mean I've certainly planned for that freeze to be a certain window and then something isn't ready and we have to expand that window. I think sometimes it is just, yeah, it's just saying, "Oh wait, that didn't work as much as we planned or not." And you have to just back out and learn and go forward again, which is really hard as a consultant or as the web director, whoever's in charge on then the organizational side. But sometimes that's what you do. I mean we've seen it publicly in lots of places, whether it's a migration or just a rollout, there's been plenty of disasters where they've had to go back and rebuild everything.

You're talking about healthcare.gov, aren't you?

That's the first one that comes to mind.

Second straight month we've mentioned it actually.

What can you do to prepare customers going into a project? How do you make sure that the customer understands that migration needs to happen? I have had some tragic situations where customers just thought it was automatically included, but how do you set a customer's expectations that this is a big part of the project? Nobody wants to pay for this. They want to pay for the new house, they don't want to pay for the moving cost.

I think that's just where making it part of the project definition and scoping and saying, "This is how it's going to work." And to keep migration, this much of the product, a small part at the end, you have to do all of these things to prepare for it. It's like you have to pack, you go through your stuff. Going back to the moving analogy, you have to go through your stuff, you have to get your boxes, you have to get the bubble wrap and the blankets and all of the things, and then you can have it go smoothly. The people who move a lot, I live in Washington D.C., so people around here move a lot. They get to be experts and they can do that really fast and they've learned over time not to accumulate too much stuff and how to go through the packing process and get unpacked easily, but they didn't do that the first time they moved.

(20:17)
We, as consultants who can say we've done this how many times, we know how this works, this is how it works, and these are the things you need to do to make the migration as painless as possible. It's never going to be painless. I think that definition and setting expectations upfront is something that a lot of people just don't do very well. Honestly. I think dispelling talking about the horror stories and the success stories as part of that, because a lot of people, like you said, think this is magic and it all can just be automated, but rarely can it. Now working for a CMS vendor, we have some customers who knowingly come in saying, "We have to move in a month so we know we're just going to," they call it lift and shift. That goes pretty smoothly because you're just moving ... It is a technology problem. But then they get in and now like, "Okay, now we have to remodel the house." I meet with customers that are like, "Okay, we did the lift and shift. Things are okay, but they could be better so we're going to do some remodeling."

(21:35)
That's when the migration is like, "Okay, well how are we going to do that? Are we going to do it all at once? Are you going to move out and we're going to tear down everything and rebuild it? Or, do you want to do one room at a time, a few content types at a time and then move that over?" Does it make sense to pay the developers to do scripting? Depends on the amount. To me, the answer to that is always depends on the amount of transformation, what kind of structure you're going from to what you're going to. Yeah, it's just always a bigger. Sometimes press releases, they're generally the same structure no matter where you're building them and how you're displaying them. They can usually be moved over en-masse. You start with that, the easy stuff and then you go, "Okay, what is our most important content?" We want to make sure that's tip-top. We'll hand move that over and then everything else gets something in between. I think it's just having these realistic discussions and applying the lessons and giving them horror stories if they need them.

You use the phrase lift and shift and I always love that phrase because it's a very common phrase and it boils a very complex process down to a very simple rhyming phrase. I always imagine Ross Geller screaming "Pivot." When they're trying to get the couch up the stairs. You can scream, "Pivot." All you want. You can say 'lift and shift' all you want. It's more complicated than that. Do you think customers today are even cognizant that there's a migration involved or are they just making assumptions that content sort of moves? Do they even know? Do they even understand that? Or, in projects especially when you were in professional services, were you having to explain, "No, this is a part of it."

I hate to say it, but it depends of course. It depends on if someone has lived through a horror story before, whether they were directly part of it as part of a development team or a design team, or if they were on the business side and suddenly they remember their colleagues having a problem or they couldn't update the website because something didn't work. By now, like you said, it's been 30 years. People who are in senior roles have done this many times before. I think it may be happening less often because more people have experienced this more often than they used to when it was new. But certainly, there's always going to be people who think it's a technology problem and won't plan for the content and then wonder why things haven't changed.

It really is a human social engineering project in a lot of ways. I wonder if we're going to see a point where migration is used as a vendor feature. You and I both work for content management vendors, Carrie. I'm waiting for the first vendor ... I don't want to say the first, because you see it every once in a while. It's not like it's unprecedented, but at what point is the vendor going to target a competitor with a prepared migration? If you migrate from our competitor to our system, we have this canned migration to move things across. I'm curious when we'll see that.

Well, we have something like that and I am not sure how it works because I don't know how you do that.

Because here's my point I've always thought is that every site is kind of a unique little snowflake, and if you migrate everything like a one-to-one migration, every type, you might just have now a really, really bad implementation in another system because you've tried to jam processes and paradigms from one system into another one without modifying. So I don't see how that would work every migration. Is it fair to say that every migration is a reimplementation?

Headless CMS should be able to work that way. Right? You can only do that if you have the exact structure you want and you want to keep that and then you just have to change whatever the scripts, all the code and then it really is but I've never met anyone who wants to do that.

There is a theoretical push button migration out there somewhere. I've never seen it.

It sounds like you're both sort of alluding to the idea that the CMS doesn't matter in the migration itself.

We're CMS vendors, Corey.

I'll say it.

[inaudible 00:26:34].

You're just moving one data model into another data model. The CMS does not matter at all in that situation with maybe, I mean it obviously does in the way that content is structured might be different in each of those, but ultimately it's just you're moving from one house to another. It just happens to be built different.

That's the promise, especially with headless CMS because you're front end agnostic. You're just building a content repository that has an API. Right? Theoretically, you could do whatever you want on the front end. It doesn't matter what the back end is as long as the API is connected properly. Yeah, that doesn't really happen because there's too much in the CMS tied to the formatting a specific presentation. Yeah, I mean it should be able to. The last time I was in-house, I was a web director at an organization and we could not change CMS. We did update or upgrade our version of the CMS we were using and we could do only so much structure. My goal for that was to make the structure as good as possible so that when it was time to go to a new CMS, the migration would be as painless as possible, that you would only have to adjust things based on the new CMS' functionality.

(28:09)
I have no idea how that worked out for them. I left before we ever moved CMS'. But, I think if you go into a project like that and you know that you are aiming for the best structure possible, then it's more likely you can have a more seamless migration but I don't know how many people approach it that way.

Sure.

When you think about it, I'm like, how many times does somebody move house into another house with the exact same floor plan size and layout? That never happens. You're moving to another house for a reason and there are different paradigms in the way things are put together. Some of the things always have to change. Congratulations, Carrie, on being part of the most depressing episode of this podcast.

Just wait, Deane, next month we're talking about QA testing, so there's always room to go down.

I hate to get cynical about migration because I really love them. I really think it's kind of fun because there's really an opportunity to clean up your content, do some really neat things. I enjoy moving data around. That's kind of like a geeky thing that I really enjoy doing, but there's no way to deny that it's the thing that everybody wants to pretend you don't have to do.

Do you want me to tell you about my favorite client?

Please, please.

Who did everything, I don't even know if they were using a CMS when we started, they were moving to a CMS or a different one, I can't remember which. They launched early because we started with the content. We did content modeling, content design based on the model and worked. Even though I wasn't part of the implementation, the points of contact at the client learned, they picked everything up and they understood what was happening. I had a good communication with the implementation and design vendor, and so they did wire frames and mock-ups based on the structure and the content design and could specify how the CMS should be built to accomplish this. Moving everything over took less time than I thought. There is hope.

The thing is you had a customer that took your advice.

Yes.

It's a sad truth of professional services and consulting business that that is a rarity.

Yes. And this client had, they got improved SEO. One of the biggest wins that I took from that was one of their accomplishments was they stopped fighting with their CMS. When they needed to publish content, they just published content. That's a huge win. It's not a migration win, but the fact that they were able to get into their new system quickly, settle in, and start publishing and doing what they needed to do for their business is a huge accomplishment.

I think we should close on a win, Corey.

Do you want to talk about the CMS you work for?

Yeah, I work for Sanity, the composable content cloud. Yeah. I work with our customers to help them avoid painful migrations just as far as we can. We don't have professional services, so we're more in just the giving them guardrails and guidance on how to use Sanity to fix their problems.

Then the book, I see the book behind you.

The book is Designing Connected Content. If you follow that process is basically the process that I'm talking about that has led to successful, less painful migrations.

You almost said painless.

[inaudible 00:31:54] I almost said painless. But it is the process that allows you to do that with lots of extra things thrown in. We refer to Dean's book and content design by Sarah Winters and all kinds of other books that will help people on the more content strategy or editorial side or information architecture. But overall, it's a pretty clean process that people can use.

I have something to promote that relates to Carrie. I have for seven years, I have taught two courses at the University of Graz, Austria. Carrie is joining me. Carrie and I are going to be co-instructors of a course, and I mention that because the advanced course at this time uses Carrie's book as a textbook, which is why I'm so familiar with Carrie's work. I'm assuming that we will continue that when Carrie comes on board, but we are going to co-teach our two courses, and so hopefully we'll have a migration component to reign on the parade of all these naive, innocent, hopeful students.

That's great. Deane, you should have them use our book as a textbook.

I should. Yeah. It's not that kind of course.

It's right there. Carrie, I know you're not currently working as an independent consultant, but is the Tanzen consulting site still a place people can go to see old thoughts on IA and stuff? Your old thoughts because IA has changed so much in the past, however long?

Yeah, it never changes. Yes, tanzenconsulting.com. I still have my blog up for now. Someday I will be moving it, but I don't know when that is.

It's almost like-

I got to migrate.

It's almost like it's a migration problem.

I am avoiding my own painful migration to a different system.

Congratulations on becoming your own worst enemy.

We're always our worst clients, aren't we?

Yeah, absolutely truth. Thanks Carrie.

Thanks Carrie.

All right, thanks.

Hey Deane, what an interview.

I predicted two things. Number one, that it was going to be somewhat depressing and I apologize to Carrie for that. Also the other thing I predicted is that we were going to beat the house moving analogy to death, which we did because there are just so many similarities to moving content to moving houses and nobody likes moving. I've lived in the same house for 24 years, Corey, because I'm too damned lazy to move. Probably why I don't move from CMS to CMS.

I thought of an even deeper level of house metaphor, and that is around the idea of migrating blocks. If we're thinking about migrating blocks or elements within the house, it's like moving a bookshelf within your house where you have to essentially migrate a bookshelf on its own. You have to remove all of the books from the bookshelf, then you have to figure out where the bookshelf is going to go, and then you have to remigrate all of the books back on the bookshelf

In the right order.

In the right order. Then I'm like, I'm not going to do this. This is too deep.

No, that's a really good metaphor actually. We didn't even touch on, and this gets a little more technical, but we didn't even touch on most CMS' now are kind of compositional. Right? There's page composition where you drag blocks on the page and organize them. No two CMS' do that the same way. Not only do you have to move this page now, but you have to move all of the components, either you flatten them and make them part of the page, or you have to move all the components separately. Then once you move all the components separately, you have to reassemble them into looking like the way that they looked like in the old CMS. What that means is now you have ordering issues. You got to move the blocks and the components first so they're there when the page comes in. What always happens is it's just too much work and people just rebuild the pages. They just rebuild them and they don't actually migrate a thing, like a landing page or something. A big part of migration, unfortunately, is just rebuilding.

Yeah, yeah. I mean it's the difference between, you think about like, "Oh, we're going tore going to rewrite all of our content so we don't have to worry about migration on this.' It is essentially the same thing. You are rewriting all of those things because you have new blocks, new tools, new elements, all this new stuff that you have at your disposal that you might not have had the first time if you're thinking about doing a refresh or design upgrade or moving to a design system.

Corey, if we were trying to take the depressing edge off that interview, we failed miserably.

Did we make it worse?

I think we made it worse. We should just quit here.

Okay, well that wraps it up. Thanks again to our guest, Carrie Hane, author of Designing A Connected Content Plan and Model Digital Products for Today and Tomorrow. It's a really long title, just you can look for Designing Connected Content. It's a big yellow book. I used to have a copy of it and I believe now, Deane, that you have my copy.

I am willing to bet. When I left with Blend, I stole a bunch of books and I'm willing to bet that was one.

Yeah, I couldn't find it the other day and I bet you have it. You can read more about her work at Tanzen Consulting. That's T-A-N-Z-E-N C-O-N-S-U-L-T-I-N-G.com. Or just look it up. T-A-N-Z-E-N is what it is.

There is something, I won't speak for Carrie, but there's a particular reason behind that word. It's like dance in African or something. I don't know. I've known Carrie a long time and she's told me this story like seven times and I've immediately forgot it every time. But there is a reason why it's called.

Okay. The Web Project Guide is a product of Blend Interactive, a web strategy design and development shop that builds the websites and guides teams through complicated web and content problems from content strategy and design to yes, lots of migrations we're dedicated to making great things for the web. And this is one of those things. This is episode 21 of the Web Project Guide, which also corresponds with chapter 21 of the book Migrate and Populate the Content. You can read the full text of this chapter at webproject.guide/migrate. Every migration project starts with a lot more work than just the migration itself. It's a scoping, it's a modeling, it's technology project first and foremost. If you need something physical to drop on your boss's desk and say, "Listen, this is a real thing that we have to plan for." You're in luck, because Deane and I have published a physical copy of the Web Project Guide, and you can get your own copy at order.webproject.guide, and there's also a digital copy available.

It will get your boss' attention. It is very large, and when you drop it on their desk, it will make a loud, loud bang.

Yeah, it'll thud. The thud is louder depending on how high up you drop it from. Finally, give us a five-star review on Amazon or on your pod catcher. We love stars, specifically if there's five of them, I don't know. Thank you for joining us this month. We're trying to bring the energy back up because wow, how depressing was this? But we'll be back next month to talk about a much more entertaining topic, and that is getting a new site up and running live. Until then, go do amazing things.

Good luck.