Making the Leap to a New Platform

(Why It’s Not As Scary As It Seems)

By Evan Stos

When doing platform implementations, it usually boils down to two scenarios:

  1. Moving a process from spreadsheets, Word documents and emails into an automated platform
  2. Moving from a platform that “isn’t cutting it” to a new platform with better features, performance and usability

In my experience, the difficulty level associated with both #1 and #2 is relatively the same, but the customer anxiety associated with #2 usually far surpasses #1. Moving away from spreadsheets, in the customers’ mind, is typically easier for them to visualize: I have columns and rows of data. I’ll move that data into a new system and implement workflow rules, access control and reports/dashboards along the way. Bada bing, bada boom…new system implemented!

Frankly, customers often think that moving from one platform to another (scenario #2) is “scarier” than moving from spreadsheets into a platform (scenario #1). But the reality is, the spreadsheet-to-platform conversion is usually more onerous! Why, you ask? When moving from a spreadsheet, there is typically more to consider, since you’re coming from a place where systematized workflow and notifications, granular access control, and the ability to dynamically show/hide data aren’t options.

In contrast, when you move from one platform to another, you’re coming from a place of structure and “rules.” Now, maybe you don’t care for those “rules” or feel they are lacking (which is probably why you’re switching platforms in the first place). But in terms of putting together requirements for the new platform, you have more of a foundation on which to build. Conversely, putting together a process flow document or specific access requirements where none previously existed can be a more mentally laborious process.

This is a great segue to the lone shameless plug for this blog post: Whether you’re trying to accomplish scenario #1 or #2, we have several resources available to help with crafting platform implementation requirements.

The best way I’ve been able to demystify the scary part of platform-to-platform migrations for customers is to do some “compartmentalizing” of my own. Essentially, these are the 4 primary goals you need to accomplish for these types of implementations:

  1. Migrate the configuration
    1a. Enhance it based on newly available functionality
  2. Address access control rules for users/groups
  3. Migrate record data
  4. Migrate attachments

Now, I’ll provide some additional context for each of these items.

1. Migrate the Configuration

This is fairly straightforward. However, “1a. Enhance it based on newly available functionality” is less so. Obviously each platform has its own strengths and weaknesses from a feature/functionality perspective, so we don’t want to simply migrate the exact same configuration over to a new tool. We want to make it better. Therefore, this is where concise requirements come into play. Ideally, your requirements point out some primary “pain points” being experienced in the legacy platform that can be solved (or at least be made less painful) by functionality in the new platform.

2. Address Access Control Rules for Users/Groups

This step is akin to #1, but I felt the need to call it out separately since access control is typically where platforms differ the most from one to another. Ensuring that access rules are converted properly when migrating platforms can be a very methodical and detailed-oriented process, but in keeping with the overall theme, it’s still easier to move from one set of access rules to another than from ZERO access rules (spreadsheet/Word doc/etc.) to a bunch of them!

3. Migrate Record Data

For this step, the majority of platforms I’ve worked with have a way of getting record field data out in a report format that could then be exported to a .CSV or .XML file format that can be imported into the new platform.

4. Migrate Attachments

This step is somewhat related to #3; however, the method by which attachments are moved from one platform to another can vary widely. Many allow an API to “bulk-load” attachments into records (once they’ve been imported into the new system, of course). Some have their own separate “attachment loading tool” that allows for them to be loaded from a shared drive based on an established schema. Point being, this is usually the final piece involved in migrating from one platform to another, and the most difficult part is determining the method(s) by which the attachments can be bulk-loaded.

For those of you who are currently migrating from one platform to another (or are about to), I hope this post helps to alleviate some of the stress and anxiety associated with it. Oh, and for those of you who are migrating from a spreadsheet to a platform, don’t worry. You’ll be fine as well…albeit you may have to be a little more creative with your requirements!

Featured Resource

Making the GRC Leap – A Platform Conversion Guide

Considering taking the leap from a dated GRC platform to a modern solution? Our step-by-step approach to platform evaluation, selection and implementation can help.

Like What You’ve Read? Subscribe for More

Join the Onspring Insights newsletter for monthly updates from our blog. You may unsubscribe at any time.

NOTE: By submitting this form, you confirm that you agree to our Privacy Policy.