Thinking the Unthinkable; or, How to Prepare for a Platform Migration
•Download as PPTX, PDF•
0 likes•40 views
Delivered at the Society for Scholarly Publishing 2018 meeting as a pre-meeting seminar. What scholarly publishers need to know when changing platform vendors and migrating journal and book content. Presented by Allison Belan (Duke University Press) and Karie Kilpatrick (American Physiological Society)
Recommended
More Related Content
Similar to Thinking the Unthinkable; or, How to Prepare for a Platform Migration
Similar to Thinking the Unthinkable; or, How to Prepare for a Platform Migration (20)
Recently uploaded
Recently uploaded (20)
Thinking the Unthinkable; or, How to Prepare for a Platform Migration
- 1. Thinking the Unthinkable Or, How to Prepare for a Platform Migration SSP 2018 Seminar 3 May 30, 2018
- 2. Seminar Overview The Publisher Perspective The Librarian Perspective Your Perspective
- 3. Agenda 8:30 – 8:45 • Introduction to the Morning 8:45 – 9:55 • Publisher Perspective 9:55 – 10:10 • Break 10:10 – 11:10 • Librarian Perspective and Workshop 11:10 – 11:30 • Discussion and Questions
- 4. A Note on Terms Publisher Librarian Vendor Platform Migration
- 6. Introductions Karie Kirkpatrick • American Physiological Society (APS) • Digital Publications Manager • Previously at MIT Press Allison Belan • Duke University Press (DUP) • Associate Director, Digital Strategy and Systems Coordinated RFP and selection process Project leads for migration
- 7. Where We’re Coming From Duke University Press • Publisher • Humanities & Social Science • Multiple publication formats • Books (2500) • journals (52) American Physiological Society • Society • Biological Sciences • Single publication format • Journals (14)
- 8. Overview Open Discussion Lessons Learned Post-Launch Organization and Management Planning
- 10. Plan as Far Ahead as Possible • Procuring resources (budgeting, hiring staff, consulting services) • Obtaining back content and organizing archive • Conducting website survey • Compiling list of requirements and “wishlist” items • Completing RFP – allow for at least 9 months • Obtaining master schedule • Organizing internal staff teams
- 11. APS RFP Timeline, 2016 JAN-JULY • Draft RFP • Select Vendor Pool JUNE-JULY • Hire Consultant • Complete Final Version JULY • Distribute RFP JULY-SEPT • Answer Questions • Receive Completed Proposals SEPTEMBER • Evalution • Selection of Shortlist OCTOBER • Vendor Presentations OCT-NOV • Vendor Scoring • Follow-Up Questions • Selection NOV-DEC • Contract Negotiations
- 12. DUP's No RFP Route • Go under NDA with each potential respondent • Make all key business strategy and planning documentation available • On-site presentations of platform's capabilities in light of material June • Build document set July • Contact vendors • Execute NDAs Aug – Sept • On-site presentations October • Finalist list • Follow-up Nov • Select preferred vendor • Validate requirements Dec • Contract negotiations
- 13. Wait! Did you ask your customers? • Librarians • Members Some concerns: • Accessibility: WCAG 2.0 AA, VPATs • Trusted access routes (members, alums) • Text and data mining • Institutional branding • Integrations with preservation, discovery services • GDPR (!?!) Know these before you send RFP Consider setting up advisory boards
- 14. Project Organization Projects within Projects, Teams within Teams
- 15. Breaking It Down Site Design & Build •Global •Journal •Book •Society •Products 1 Content Migration •Content Analysis, Design •Archive Delivery •Conversion •Load •QA •“Gap” Content 2 Data Migration •Products •Customers: institutional, individual •Usage: publisher, COUNTER •Legacy Site: alerts, accounts, purchases 3 Partner Communications •Library •Editor •Member •Individual •Alert subscribers •Compositors, data vendors 4 Team Lead Team Lead Team Lead Team Lead Project Lead
- 16. Vendor Team Conversion Vendor Platform vendor? Conversion house? Project management? Platform Vendor Roles Project Methodology Governance Retiring Platform Vendor Timelines Data, content transfer Obligations (both ways) Composition & Data Vendors Pre-launch BAU New specifications Post-launch transition
- 17. Scheduling Know Your Milestones
- 18. Scheduling Method • Set your launch date • Identify the least flexible process • Set the schedule based on that • All other processes align to that schedule • Accept that effort must fit within a time box • Accept risk to accuracy, feature-set
- 20. Platform DUP Schedule Converter Converter - Platfrom Sprint 143 Sprint 144 Review Nov 13 Launch Key Conversion June 26 Validation, Programming Aug 8 Backfile Loading QA of Conversion Sept 9 Correx, Programming Oct 27 Review corrections Nov 3 Resupply Nov 10 Reload Nov 17July 17 CONTENT SITE Nov 13 Launch Sprint 145 Sprint 146 Sprint 148, etc Review 6/28 – 7/7 Review 7/19 – 7/24 Review 8/9 – 8/14 Sprint 147 Review 8/30 – 9/5 9/20 – 9/25 ::BETA Ready for content load Ready for data load
- 21. Hidden Shoals Things your old platform “just handled” (black boxes) Shibboleth Abuse monitoring configuration PubMed Central, other deposits DOI deposits Business rules built into platform-side processing URL construction and patterns Redirects Things you know some— but not enough—about Identity, access integration approaches, pros/cons Your data hygiene (lack thereof) Deep business rules: known but hard to document Lost institutional knowledge Metadata surprises Library discovery ecosystem
- 22. Post-Launch It’s a Marathon, Not a Sprint
- 23. Your Work Is Far from Over Further testing and more testing (Re)Training and cross-training Verifying integrations and deposits are working properly Monitoring new content submissions Fix catch-up Driving traffic and analyzing usage Re-engaging users Planning site improvements Internal “post-mortem” Supporting, communicating with customers
- 24. Lessons Learned There is no such thing as starting too soon Know your blind spots Stick to deadlines at every stage—or testing will suffer Start early on custom integrations Deep dive on customer, product, access data & interfaces Expect your back content to be a mess Be ready for content fixes and consequences Involve librarians in the process Google makes the rules – listen to them! Be prepared for traffic changes Provide strong leadership
Editor's Notes
- 15 MIN (8:30 – 8:45) ALLISON
- 1 MIN ALLISON
- 3 MIN ALLISON
- 5 MIN (end 8:45) ALLISON I’d like to set some basic definitions for terms you’ll hear today. First, though, I’d like to know more about who is in the room By show of hands: Who works for a publisher or society? Keep your hands up if your org has done a platform migration in the past 5 years Who is in the vendor or services sector? Who is a librarian, or works with library services? DEFINITIONS . . . Finally: During this seminar, we’ll be discussing our experiences. We won’t be assessing the relative merits or demerits of any given platform or publisher. Our aim is to give you actionable insights into managing your own migration, either real or hypothetical. END BY 8:45
- 10 MINS (8:45 – 8:55) ALLISON Let’s dive in
- 3 MINS ALLISON Karie: Digital Publications Manager at American Physiological Society 4 years at APS Prior to that, 10 years in production and technology at MIT Press Allison: Associate Director for Digital Strategy and Systems Been with DUP for 14 years – 8 as journal production manager, 6 in this role ***ANIMATION*** We each served as the leader of our organization’s migration effort. KEY PIECE OF ADVICE: Make 1 person the clear leader of the project They must be Trusted Empowered Given the resources they need If possible, dedicated (ACB ~80%)
- 3 MINS ALLISON So you know where we are coming from, here are some key characteristics of each organization that shaped our migrations. Publisher vs Society: different constituencies For APS, there are members and journal editors who need to be served and supported. DUP: our greater focus is on the institutional customer. Our relationships with our journals' editors are a bit more indirect. STM vs H&SS: Journal platforms were built originally to support STM content characteristics. For H&SS: places where platform's existing content model doesn't support some common H&SS content attributes, or the UX doesn't fully support the way that H&SS scholars publish or read scholarship. Multi-format vs Single Format
- 1 MIN ALLISON END 8:55
- 10 MINS (8:55 – 9:05) KARIE
- 3 MIN KARIE Staff: APS beefed up their Digital Publications Department (me, DP Coordinator, Web Specialist) Back content: APS did not have an internal archive; obtained XML, PDFs, images along with supplemental files (chose to include ahead-of-print AND final content) Web survey: sent out to public via social media, to APS members, and editorial board members Requirements and wishlist items: helped to drive the entire process (RFP, contract negotiations, migration) RFP: APS had distributed one about 5 years prior; distributed different RFPs to prospective vendors and current vendor; hired consultant to help project manage and negotiate Contract signing: Appendix included requirements and wishlist items (denoted which were required for launch and which could be post-launch activities) Internal organization: use master schedule to determine how to best determine who should be included in migration at various stages
- 2 MIN KARIE
- 2 MIN ALLISON For a couple of years prior to platform search, DUP had been engaged in researching and building an integrated digital strategy to support the Press’s strategic goals. Had a lot of critical documents on hand describing this [Explain slide] ***ANIMATION*** From engagement with potential vendors to contract was 6 months – but work began long before that.
- 3 MIN KARIE If there are big things like this, that have to be cooked into the platform to work, you have to get the commitments at RFP. Very tough to make them happen later as a single-customer driven development or customization. END 9:05
- 20 MINUTES (9:05 – 9:25) ALLISON
- 4 MIN ALLISON Big project—break it down into smaller projects We divided into 4 (I wish we’d had a 5th – Content Workflows) Project Lead Team leads on each subproject, with people on those teams.
- 4 MIN ALLISON You will need to coordinate multiple vendors Content conversion: know if you are responsible for delivering to platform content spec, or if platform will somehow manage the conversion or transformation Don’t forget the retiring platform vendor: good planning and clear expectations will make this work. (Tip: figure out how to support your own asset and data export needs as much as possible)
- 3 MIN ALLISON Here is a basic method for scheduling something like this.
- 2 MIN ALLISON Point here: schedules get complicated FAST Must have a good way of showing it, sharing it, managing it.
- 3 MIN ALLISON For us, the site build, tied to the vendor’s sprint schedule was the least flexible. So, I got that laid out on a timeline that ends at LAUNCH Then, added in the key milestones for the other major subprojects: content migration and data migration ***ANIMATION*** Then I developed the next most complex timeline to hit those key intersection milestones Etc
- 4 MIN ALLISON No project plan survives contact with the enemy – the unknowns that become known END 9:25
- 10 MIN (9:25 – 9:35)
- 5 MIN KARIE Testing: you can never do enough Training: time to fill in the gaps (pre-launch training can be a bit too basic) – and change is hard (esp if you’ve been working with the same system for over 20 years) Integrations and deposits: even if your vendor tells you they’ve completed it and it’s working, it’s best to find out for yourself Content submissions: it is likely that your compositor and other third-party vendors (e.g., manuscript submission system) had to adjust their technology and procedures to conform to the new platform; make sure these processes are running smoothly; extra content QA Fix catchup: you will be faced with lists of fixes to apply to your content (or other areas) that is minor enough and time-consuming enough that it can wait Driving traffic: have a campaign in place for promoting your site (signup for content alerts, incentives, teasers) Re-engaging users: You may have lost all of your alert subscribers Analyzing usage: like testing, you cannot do too much analyzing; this will help you find potential breaks or missing links Site improvements: you will quickly discover what isn’t working the way you thought it would; stakeholders/users will recommend better functionality; generating roadmap to help drive future innovation
- 5 MIN KARIE / ALLISON END 9:35
- 9:35 – 9:55