Why estimate? I'm not getting more resources for this site migration.
We recommend that clients do a simple back-of-the-envelope calculation to determine if they have the resources they need for a site migration. One response we've heard more than once goes something like "Why estimate? I'm not getting more resources for this migration."
Example rough calculation: Let's say that you discover or estimate that on average a person can migrate 4 pieces of your content a day. If you have 20 people working on the task then that's 80 pieces of content a day. If you have 80,000 pieces of content, then that's going to take 1,000 days.
Even if we assume that you cannot bring in more resources, these are some of the actions you can consider if you discover you don't have the resources you need:
- Migrate less. Similar to moving from one house to another, a migration can be a good time to get rid of old (or redundant or trivial content). If you see you don't have time to move everything, then you could decide to not move sections of the site, certain content types, certain ages, or content that is viewed very infrequently (or a combination of the above). Also see The Web Diet: How To Simplify Your Web Site.
- Migrate at lower quality. This one sounds crude, but it could be that some content (probably the same stuff that was being considered not to be moved at all) could be moved with less quality than what you were hoping for (for instance, maybe it has some tables that aren't sized correctly or other formatting that's a bit messed up). Obviously this probably only makes sense when migrating a larger site. Also, it's better to do this proactively in a controlled manner than in an uncontrolled manner in the middle of a migration (so that, if unplanned, you may inadvertantly migrate important content at lower quality).
- Automate more. This can be related to the previous bullet, since you may discover that you can automate large swaths of content if you're willing to deal with a bit lower quality. That said, a knee-jerk reaction (especially from the technical team / systems integrator) may be that it's "not possible" or too hard. If you have the facts of the resources needed for manual migration, you may discover that it actually is worth it to dig a little deeper to determine more of what can be automated. A common complaint will be that the content isn't consistent enough, but there is often more consistency / patterns than immediately obvious, especially if you're willing to scrape pages in creative ways. At any rate, even if you are attempting to migrate and the technical team provides reports of what cannot be migrated, I would recommend digging deeper if the same issue is happening frequently.
- QA less for some content. It may be that key pages need to be manually reviewed, but this doesn't necessarily mean that all pages need this treatment.
- Phase. In general, a pilot can help you work out the kinks in your processes before the masses start using your new CMS. Also, a pilot can help you better gauge how long things will take, so you can re-run your estimates. After pilot, if you know you don't have the resources you need for the entire migration to occur in the needed timeframe, you can phase them more confidently based on your estimates.
- Improve training or the content entry tool. You may discover that users are getting tripped up on particular steps of the content entry. Sometimes this could be improved by training, or you may find that rearranging the content entry screens would vastly speed up the task.
- Set expectations. Communications during a migration is key, and easy to overlook in the heat of a complex migration. One of the main steps is to create, communicate, and re-enforce a compelling vision for the migration. In addition to that, if you discover that the migration will take longer than desired, you can *communicate* about it. Hopefully that compelling vision is strong enough that people will be ok with a longer migration time if that's just the fact.
A brief note on estimating: as the example above illustrates, you want to start by estimating the number of content items someone can migrate in a day. Depending on the complexity of the migration, you may want to dig one layer deeper to break this down a bit more by type of resource (for example, staff, intern, outsourced) or content type (simple flat page vs. complicated structured page vs. old crusty page with bad HTML). Also, if you are planning on using non-staff resources, then be sure to consider the extra documentation, training, communication, coordination, and QA time that may be required of folks that don't have all the implied context of your site and organization that staff have (an upcoming blog post will probably cover this in more detail).Also, see Large Web Site Migration Checklist and Five Suggestions for a Successful CMS Migration. The topic of migration is firmly in the Execution layer of Web Operations Management, so please also see our definitions of Web Strategy and Web Governance which need to be in place for a successful migration.
14 weeks 5 days ago
28 weeks 4 days ago
29 weeks 4 days ago