Content Migration Overview for Developers

This guide is for developers who have experience using a restful API, or for those with technical experience in mapping and migrating data.

Some things to think about as you discuss these options are:

ANS (“Arc Native Specification”) is the collection of schema documents that comprise the Washington Post’s definition of “content”, in so far as content is passed back and forth between systems in the Arc XP ecosystem of applications. ANS is the content’s data such as headline, subheadline, etc.

More about ANS can be found here: https://github.com/washingtonpost/ans-schema#readme, and most of the high-level elements are found in this directory https://github.com/washingtonpost/ans-schema/tree/master/src/main/resources/schema/ans/. ANS versions vary over time. As a rule, develop on the most recent version of ANS that is available.

It is important to become familiar with ANS so that you can correctly map your legacy data to Arc. Think of ANS as pieces and parts to a story or a video (headline, images, body text, embeds, metadata, tags, authors, etc). These pieces and parts have their own existence outside of the story, and one or more stories can use these objects with references.

For example, an image inside of a story is a reference to an image object in Photo Center. To map an image to Photo Center, you would use the image schema: https://github.com/washingtonpost/ans-schema/blob/master/src/main/resources/schema/ans/0.10.8/image.json. As another example, story tags (or topics) would be references to Tag objects in Tag Center. The schema for this is here. While Tag Service is not required, and stories can have reference-less tags (tags that only exist on that story) and tag pages can still be built using Content API, having all of your Tags in one place to be able to manage is better long-term. It removes the clutter of having duplicate/extraneous tags such as “car” and “cars”.

Before you begin migrating, it is a good idea to clean up legacy data as much as possible. For example, do an audit of your taxonomy. Do you have older, superfluous tags that can be deleted? Do you have redundant tags that can be merged together such as “robot” and “robots”? Are there old pages/stories or unused images that no longer get traffic and can be excluded or deleted? Are all of your authors still necessary, or can some be deleted? This will help your legacy data come into Arc XP a bit more organized.

Mapping your content will be the largest lift in your migration. You will need to test and retest your mappings as they come into ANS to ensure all scenarios have been accounted for.

If you find that some of your data does not exactly map to ANS, but it is information you would like to keep, you can use the Additional Properties to store this data. This array can be structured any way you like, but aware that these fields are not currently searchable in the Content API.

If you have any questions about rate limits for migration, contact Arc XP Customer Support. If your site(s) will be using Arc XP Themes, see Migrating Data for Themes as you are planning your mappings.

You will likely build a set of classes to process each type of content (images, tags, authors within an article). We recommend starting with basic data fields, then moving on to individual story elements, iterating through all of the elements in your legacy data. Start small, and then build up your handler library.

Arc XP recommends that your source data is sent to ANS in JSON format. Clients onboarding onto Arc XP have the option of using Migration Center, the Arc XP API that will handle the work of deploying Arc XP ANS to the correct Arc XP product suite for an ANS content type.