How content services can speed up cloud content migration
During a continuous, or hot, migration, a content services platform can move content from a legacy repository to a new one -- a crucial IT tool for hybrid cloud on-premises shops.
Many new enterprise content management efforts focus on content services. When used properly, these services help streamline the creation and deployment of content-centric technologies. Cloud-based providers are at the center of this approach, as providers design cloud services, at their cores, to operate through these services.
However, migrating large volumes of content to the cloud is time-consuming because bandwidth between a data center and cloud environments is much smaller than that between server racks. But when properly planned and implemented, a content services platform (CSP) can help speed up and simplify content migration.
What is a CSP?
CSPs are cloud-based and provide a set of services, implemented as a collection of APIs that store content and the related metadata. Content services hide the CSP implementation details and, instead, provide users with direct access to logical business entities and documents. Users can organize, store and retrieve content by client or project rather than through a folder structure that only makes sense to the CSP implementer.
The way CSPs store content is key to continuous, or hot, migrations, where a CSP pulls content from the legacy repository as needed, presents it to the user and places it into the new repository -- as the content migration heavy lifting happens behind the scenes.
With the logical business entities that content services present, applications -- and the people who use them -- don't need to know exactly where content comes from. Instead, the content services can determine if the old or new system stores the record and return the information to the original business application regardless of where the data resides.
Meanwhile, if the new system doesn't store the requested content, the CSP can initiate a process to migrate it and its parent business entity. Then, when the person who requested the information is ready to save any changes, the new system has the original content, ready to receive the updates.
This hot content migration process can take place in a full or partial migration. In a full migration, everything migrates in bulk, and individual items move in parallel as part of a hot migration. The bulk upload identifies content that has been hot migrated and skips over it. In a partial migration, only those used items migrate. This slowly turns the old system into an archive that organizations can decommission as the system's retention requirements expire.
Should organizations build or buy a CSP?
When migrating content to cloud environments, the inevitable question is whether to build or buy a CSP. Some considerations include the following:
- If the legacy system is old, an outside vendor can reduce the risk during migration and shorten the implementation timeline for this process.
- If the organization has multiple legacy systems with continuous decommissioning, a vendor can help connect the different systems.
- If the organization has a complex information architecture, it may benefit from building the CSP. Proper information transformations may take too much custom work with a vendor.
- If the organization has in-house developers to help solve the migration challenges and support the new system, it may choose to build. If not, it may decide to work with a vendor.
- If the organization has a transformation engine that translates the business terminology into the CSP implementation specifics, it can plug in the hot migration logic. Some CSPs can perform this functionality natively.
When should a business use a CSP?
Before an organization moves to a CSP, it must confirm that a CSP is the right choice. As defined above, a CSP's primary use case is to provide content with a clear and logical business context to support business processes. CSPs are critical to digital transformation because content needs to reside where the organization can manage it.
However, A CSP is not ideal for collaborative content. Organizations should adopt a collaboration platform rather than use a CSP for that purpose. Organizations still need to manage collaborative content, but the platform where people create content is the primary source of business value. Organizations can't use a CSP to manage collaborative content because it may impose too much structure and control on the platform and remove all aspects that make it useful.
After an organization creates collaborative content, that content becomes part of a business entity. When companies add collaborative documents or entities to the transactional content that directly serves a business process, it becomes part of the organization's managed content repository. The repository captures the content's business context and creates long-term business value beyond that initial collaborative process.
Determine what content to move
If an organization moves only active content to a CSP, it can mitigate costs and accelerate the migration timeline. This move benefits both the business that consumes the content and the IT team's efforts to manage the migration efficiently. However, this move also leaves information governance experts in the dark, which can create problems.
Information governance enables organizations to know what content it possesses and where it stores the content. An iterative, hot migration makes that a challenge. To locate content, records managers must query the content service. Their purpose-built records management interface may not know the content's location, which makes compliance challenging.
To remedy this issue, instead of a hot migration for all active content, the organization may decide not to migrate content older than a defined date. That decision provides clarity as to where the content resides. The organization can then move older content to a system archive.
How to migrate to a CSP
After an organization decides to move to a CSP and selects the content to migrate, the steps are clear-cut, although they require careful consideration. A full bulk migration is a more traditional approach, though hot migration can work well -- especially to move from one cloud service to another. Follow these four steps for a successful CSP migration.
1. Create the business objects
Migrating business objects can be as simple as a script that reads from a comma-separated values (CSV) file and creates objects. Organizations can also create a utility that uses the CSP's API to create the objects. The latter approach can continually grab new objects and replicate them to the new CSP as the business creates them.
2. Migrate content in bulk
For an organization to effectively move content from a data center to a cloud service, it requires a physical storage device. For example, AWS offers an edge computing, data migration and edge storage device called AWS Snowball to move content into its environment. Similarly, Box provides the Box Shuttle service to move content in bulk to its system. Both devices can quickly move terabytes of content without overwhelming the network.
3. Perform a post-migration synchronization
Organizations can do post-migration synchronization with a hot migration approach or use API calls to actively push new objects and content into the CSP. The post-migration synchronization process can start as soon as the migration team ships the physical device to the CSP provider.
4. Switch over the content to the new system
A switch-over can take place once the IT team completes the post-migration synchronization process. Alternatively, the content services might know which content the company migrated and then pull content from the correct environment, enabling a more immediate transition.
As with any migration, a CSP migration strategy has various moving pieces. An organization must sit down with all parties to evaluate how it uses content and when its content becomes inactive and determine which options the IT team and the CSP can support.
Looking to the future
An organization must consider that its future is not static. Ideally, it would deploy one CSP to work until the end of time, but history says this situation is unlikely. Additionally, an organization should not avoid another business service because it doesn't work with its current CSP.
In the future, businesses will likely need to change their CSP provider. However, if an organization builds the business abstraction into its content services, then the systems won't need to change. Instead, the hot content migration process will start over again and slowly move content to the new platform.