Migration is the New Transmittal

Server rows. Modified public domain image from Pixabay.

In the book publishing world, a pretty clear line exists between the editorial and production workflows. That line is transmittal. For our digital projects, this line more blurry. You could even imagine it as a very wide line, with a transparency setting of 35% or so (for all the graphic designers out there), that sits on top of a list of overlapping stages in both the editorial and production columns. Or maybe it’s that space in the middle of a Venn diagram where everything converges and there is harmony. Or madness. It depends on the context.

For digital projects, the closest parallel we’ve identified to the traditional transmittal stage is migration. Migrating web projects from their development servers to the Press’s production server can be a complex process. Or it can be as easy as uploading a zip file. But even at its seemingly simplest, there are always surprises. Links are broken or styles reset or permissions denied.  And at its most difficult, it involves sometimes unexpected and time-consuming efforts from project developers and service providers. In either case, we’ve found that it’s important to go into migration with a plan, and that depending on the technology behind a project, that plan will need to be customized to suit each individual project.

After months of fine tuning and a few migration processes under our belt, we’ve narrowed down a baseline for an interoperability analysis. This analysis is stage one in establishing a workflow for the rest of the process and requires participation from a range of people. But the initial effort can prevent or at least prepare us for any complications or time sinks.

In our program, once we’ve agreed to publish a project, we solicit technical details about the project via a technology and archivability questionnaire.  This questionnaire is part of a package of guidelines and recommendations for building sustainable projects we can host and archive using the resources at our disposal. Ten of the nearly forty questions are especially useful for determining how we’ll need to prepare the hosting environment and if there are any interoperability issues we’ll need to address before migration can happen:

  1. If your code base is in a public repository, please provide the link.
  2. If your project allows access via a login, please provide instructions on how we may register for permission to view source code. (You may choose to provide this information outside of this form via phone or email.)
  3. What is your project’s primary platform or programming language? (e.g., WordPress, Scalar, Jekyll, HTML5)
  4. What secondary technologies does your project employ? (e.g., JQuery, D3, BootStrap)
  5. List any additional plugins your project uses. (e.g. Twitter feed, Google Analytics, etc.)
  6. What software, system, or browser dependencies does your project have? (e.g. Flash, Silverlight, Chrome, browser versions, etc.)
  7. Does your project rely on data that is cached and hosted along with your project or data that is queried dynamically from a third-party web service?
  8. If third-party, what API and data dependencies does your project have, and where is that data located? (e.g. map data from OpenStreetMap, statistical datasets, etc.)
  9. Are any code or source files located remotely? (e.g. web fonts, code libraries, stylesheets, etc.) If so, please list:
  10. What programming languages and extensions are supported in the project’s current hosting environment? If you don’t know the answer, please share a contact name of the server administrator or provide a link to documentation of the service plan under which your project is running.

We’ve worked with Reclaim, our hosting service, to identify these questions, and once authors and their development teams have responded to those questions, we begin working with the Reclaim team to develop a strategy for moving forward. Because each project is different, the next steps could range from setting up a group meeting to assign responsibilities, to importing and cleaning a packaged installation, to requesting certain changes from the author. In all cases so far, we’ve been able to avoid asking for major technological changes. And even before we had established the interoperability analysis phase, with collaboration between authors and developers and the Press, and the support of the hosting provider, we’ve been able to coordinate successful migrations.

It’s definitely been a learning process, but now that we’ve established a baseline for a preliminary analysis, we hope to be able to better meet the challenges of this new form of transmittal. Even though the line remains more like a plane, we’re at least hoping to give it a more defined shape.

One Comment

Add a Comment

Your email address will not be published. Required fields are marked *