Are you ready to move to a new CMS, but unsure how you're going to migrate your content?
You know that you’re bound to run into issues associated with the migration of your site content, templates, and other assets from one platform to another and have questions of how to plan out a successful migration. Here are a few tips to help you prepare your site to make your migration as smooth as possible.
View the entire webinar at https://www.youtube.com/watch?v=XCW7OMQptR0.
Presented by Blend Interactive (www.blendinteractive.com) and Siteport (www.siteport.net).
Breaking the Kubernetes Kill Chain: Host Path Mount
How to prepare your site for content migration
1. How to Prepare Your
Site for Migration
Deane Barker, for Siteport and Blend Interactive
#migration101
2. About Blend Interactive
• Based in Sioux Falls, South Dakota
• Specializing in web content management
• Implementing multiple platforms across multiple
languages
• Specializing in EPiServer
• EPiServer’s first North American partner
3. About Siteport
• Based in Long Beach, California
• Provider of automation software and services for
migrating website assets between CMS
platforms
• Supports EPiServer, Ektron, Sitecore, Drupal,
OpenText, SharePoint, Oracle Portal, and more
4. Agenda
• Definitions; what is a “migration”?
• What makes a migration complicated?
• What are some of the challenges?
• How does automation help?
• Keys to a successful migration
• Q & A
6. Definitions
• A migration is a movement from one “platform”
to another
• Usually CMS to CMS
• Occasionally static HTML to CMS
• Source Platform
• What you’re on now
• Target Platform
• What you’re moving to
7. Definitions
• Site Migration
• Movement of an entire website from one platform to
another
• Includes building out the Target Platform
• Content Migration
• Movement of all the content from the Source
Platform to the Target Platform
9. Remember…
• You need to re-implement your site in the Target
Platform.
• Unbelievably, this occasionally gets overlooked.
• “If we move all the content, won’t it look and work
exactly the same in the new CMS?”
• A website is a combination of:
• Content
• Programming
• Design
• They all have to migrate and be “re-wired” in the
Target Platform
10. Types of Site Migrations
• CMS Only (“Forklift”)
• Rebuild the exact same website, just powered by a
different CMS
• CMS and Re-design
• The same content and basic architecture, but a new
CMS and a new design
• Efficient, since templating usually has to be re-done
anyway
• Complete Re-implementation
• Fundamental changes to content, architecture, or
functionality.
• Essentially a new, ground-up implementation project
11. “We love our content, our
IA, and our design. We
just want a new CMS.”
(This is a site migration.)
12. “As long as we’re
swapping out the CMS,
we want a new design.
And we hate our content.
And do it all in a new
language.”
(This is more of a complete re-implementation.)
14. What makes a migration complicated?
• How much automation can you bring to bear on
the migration?
• Factors
• Volume of content
• Velocity of content
• Cleanliness of content
• Discrete structure of content
• Relational structure of content
• Reusability of Source Platform artifacts
15. Volume
• Your first decision is manual vs. automated.
• In a manual migration, it becomes a problem of
pure manpower
• Significant content rules out a manual migration
16. Velocity
• Low velocity content imparts a certain amount of
“leisure”
• High-velocity content becomes a moving target
• High-velocity content compresses your content
freeze
• A highly-automated migration that limits downtime
might be your only option
• Different sections of content on the same site
can have differing degrees of velocity
17. Cleanliness
• A migration is a great time to clean-up old, non-
standard content
• How “dirty” is the current HTML?
• Content coming out of a competent CMS is likely
quite clean
• Static HTML content is usually a disaster
• How predictable are the transformations?
• Can they be automated?
18.
19.
20.
21. Discrete Structure
• How structured is the content in the Source
Platform?
• How structured does it need to be in the Target
Platform?
• How much does this differ from the Source Platform?
• How cleanly can you identify and extract
individual properties/fields?
22.
23.
24. Relational Structure
• How interlinked is the content?
• Spatial / hierarchical relationships
• Ordinal relationships
• Field-level references
• HTML links
• What relationships need to be represented via
import?
• How easily can those links be resolved and fixed
after migration?
26. Reusability of Artifacts
• Templating Code (HTML/CSS)
• Content Architecture, Structure, and Navigation
• Integration Code
27. Templating Code
• If you’re not changing your design, this is highly
re-usable
• It exists on two levels:
• The templating code, which is likely useless
• The rendered HTML, which is valuable
• Re-using this is a process of reverse engineering
the rendered HTML into new templating logic
28.
29. Content Architecture
• If you’re not changing your core architecture, and
the Target Platform shares core architectural
concepts, then this might be valuable.
• It will still need to be re-implemented, but the
logical questions have been solved, which is
significant.
30. Example:
Your navigation is rendered by traversing a content tree for “parent,”“sibling,”
and “child” pages.
31. Integration Code
• Non-CMS code to integrate with other systems
and provide other functionality
• Applications
• External system functionality
• If you’re not changing programming platforms,
then you can probably re-use much of this
• If you change languages, then all bets are off.
34. Minimize the Content Freeze
• A “content freeze” is the period when editors are
prohibited from changing content on the Source
Platform
• Changes to content in the Source Platform will
have to be re-migrated or replicated in the
Target Platform.
• Content freezes are precarious and stressful to
the organization.
36. After you hit the limits of
your automated
migration, you have to
commit.
37. Do you launch with
content less than perfect,
or do you implement a
content freeze?
38. Minimize QA
• Content has to be quality-checked after
migration to the Target Platform
• This usually requires domain knowledge, which
can be expensive in terms of time.
• Less fidelity means more QA.
39. Managing Stakeholders
• When they hear the site is migrating, everyone
will want input
• Questions of whether or not to migrate Content
X can become highly politicized
• For every bit of content and functionality in your
Source Platform, someone is likely expecting it on
your Target Platform
41. The Role of Automation
• Speed up the cycle, so you get more iterations in
less time
• Standardize the migration, so you can test
migrations early in the process, then run them
confidently later in the process
• Transform content during a migration
• Handle the rote movement of bytes
42. “The Pushbutton Migration”
• In a perfect world, you can “bottle” the migration
as an elaborate macro, then just press a button
and migrate when you’re ready to launch.
• The actual, technical movement of bytes from
one platform or another might take just minutes.
• …which means your content freeze only lasts
minutes.
• The preparation for that moment might take
months.
• A Pushbutton Migration is only possible with
automation.
43. Manageability
• Large parts of a migration fall into patterns,
which don’t need to be re-solved.
• As a migration becomes more complicated, script
management becomes a bigger and bigger
problem
• The goal is predictable repeatability of iterations
• Avoid: a confusing mess of one-off scripts
• Even worse: a single person who knows how it all
works
45. Keys
• Perform a ruthless content inventory
• Limit scope, if possible
• Get enough organizational backing to effectively
manage stakeholders
• Find a competent automation solution
• Over-allocate time and budget
• Ensure enough resources are available during
the content freeze
• “All hands.”