Migration Madness
Whew, it’s been a busy few weeks—just wrapped up migration on a couple of projects, and it’s nice nice nice to end the week with a go-live!
I have a love-hate relationship with migration. There’s a part of me that really enjoys the sense of accomplishment and the feeling of organization that migration can bring. There’s another side of me that wonders whether it was worth the MBA tuition dollars to spend parts of my day cutting and pasting. What I’ve realized through all of our projects is that migration isn’t for the weak or undisciplined or haphazard—doing migration well requires tenacity, attention to detail, basic knowledge of HTML (yes, even with a CMS), a good understanding of information architecture (those hyperlinks don’t link themselves), and, IMHO, some background in copyediting and design (check out http://tinyurl.com/aveqrm, please, it’s a fantastic book for those of us who didn’t study design in college).
Migration has been on my brain lately because one of our clients who planned to do their site buildout internally asked me if I could put together a guide of sorts to let her know what to expect. The excerpt below is my top 10 list for making migration as easy and painless as it could be. Hit me up at .(JavaScript must be enabled to view this email address) if you’d like a DPF of the guide in its entirety.
10. Lock and Load. Prepare everything you need (site outlines, edited copydecks, metadata, images and their alt tags) ahead of time. Having well organized and clearly labeled files is essential.
9. Save the dates. Give yourself the time that you need. When we first started building websites, we told people to budget 15 minutes per page. Now we tell them to budget an average of an hour per page. It really does take that long.
8. Be label-conscious. This is really important for digital image assets that start out with filenames like IMG_0303.jpg. Converting these names to something more sensible like deangodenzi.jpg will make migration much smoother. Apply the same principle to clearly labeling PDFs and other documents you plan to post to your site.
7. Keep it tight. It’s better better to have a small team of good workers than a large pool of people who generate more work than they actually accomplish. And choose your people well. You want migrators who pay attention to details, because it’s the details that matter.
6. Let migrators play in their own sandbox. Assigning each of them entire section(s) for which they’re completely responsible allows them to become very familiar with the content and eliminates confusion that ensures when several people have their hands on one page.
5. Save early, save often. The page that you’ve worked on heavily—adding hyperlinks, graphics, formatted table data, and the like—will be the page that you lose when your browser crashed before you’ve remembered to hit “save.”
4. Strip. The content that you’re migrating usually comes from two places—the existing site (for pages that didn’t require any rewriting) or from copyedited manuscripts created in a word-processing program. The content that you copy and paste will carry with it some formatting that you don’t want to keep. And even the “strip formatting” function that most CMS packages have doesn’t do a very good job. Use a three-step approach to eliminate that legacy code: copy the content from the HTML page or Word document, paste it into TextEdit (PC) or a program like TextWrangler (Mac, http://www.barebones.com), and then copy that content and paste it into the appropriate CMS field.
3. Break for Life. Realize now the migration is tedious, and you can’t do it for long stretches without going a little insane. For this same reason, you shouldn’t expect migrators to get a full eight hours of migration in each day—more likely, five hours. Past that threshold, work tends to get sloppy.
2. Have one list to rule them all. Provide a single master list of edits and changes as reviewers comb through the site. And make sure that they provide clear, actionable feedback.
1. Know that it’s never over. Once you go live, expect to spend the majority of the next two weeks fixing, changing, and adding to your website. It’s normal, really. Please don’t cry.
Migration is always among the first phases in any web development to be shortened when deadlines loom. Testing always takes a hit in this regard too, but like the article says, details matter when it comes to migration. Because the deadline is about to slip is not an excuse to throw quality out the window. Be accountable for the missed deadline. Launch with your head held high knowing the final phases are done as well as the very first ones.
I’m glad someone has given this topic some exposure- much needed.
Posted on March 9, 2009 by Mike Rivera
Mike, you’re absolutely right! Migration and testing suffer the most when there’s a hard launch date and the timeline has slipped in earlier phases. Giving yourself enough time to build and test properly is essential—as we say in the office, you can’t cheat or shortchange the process.
Posted on March 10, 2009 by Voltaire Santos Miran