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.
More in:
Printer-friendly version
We've been thinking about Web governance for a long time. Look
in the thought archive for articles, webinars and presentations.
Blog Categories
Recent Comments
Related Posts
-
15 weeks 5 days ago
-
17 weeks 3 days ago
-
28 weeks 4 days ago
Comments
I see quality as a continuum. For example, the blog post above certainly is not perfect (drives me a bit crazy that we don't have a good block quote style for example), but I deemed it good enough to post. I'm actually amazed at what low quality we all now accept, from audio quality to cellphone quality, etc. Anyway, I'm a big fan of quality but quality probably isn't an absolute so I would just argue that you should carefully look at what level of quality you want to provide as a possible means of reducing work. Also, I would agree that doing it right the first time is a good goal, and that one should assume that if you move in some content at a lower quality then it will always remain that way (so stakeholders should be bought into this).
On documentation, I would propose that more documentation is a potential way to reduce resources needed, especially if non-staff folks will be participating in the migration.
I can buy into accepting lesser quality with the caveat that it will likely never be upgraded to it's former quality. But it's hard to get a lot of people to honestly accept that reality, regardless of what they say.
I just realized one detail that I may not have been clear on: part of the issue is that the content might be at exactly the same quality as it originally was but not as high quality as your new standard. For example, perhaps you allow some old content to keep tables even if your new standard does not allow this. So anyway it's not necessarily about a degradation of existing quality, but just not raising all content to the new standard.
As to the issue of people honestly accepting things, that certainly can be a problem. Hopefully by clearly planning and communicating the plan (rather than it just happening by accident / incidentally) you can at least talk these issues through more openly. Also, perhaps the incentives can be lined up correctly as well (for instance, if a group doesn't want to pay for high-quality migration and all stakeholders agree to a lower migration, then it was their call based on budget).
I think the main point is just to be openly planning and having the discussion about quality. It may be that an institution migrating may decide only the highest quality is acceptable, but then the other factors should be considered as well.
Thanks again for the discussion on this point.
One of the challenges in content migration is that people think it is a one-time thing and so choose disposable methods that feel convenient at the time. That they are willing to sacrifice content quality (and dollars!)by getting the content re-keyed offshore or cobbling together ad hoc scripts shows that migration is not the real problem. The real problem is the absence of a content governance strategy. If such a strategy is not the driver behind the content migration then what does it matter if the content does not meet a quality standard and that there are no policies established in the migration to maintain that quality once the content is migrated. Ultimately the value in migration is when it rolls up into a governance strategy that ensures that the total cost of the content is minimized, exposure to compliance risk is reduced, worker productivity is maximized and the organization’s key knowledge assets are protected.
Post new comment