How to Avoid the Custom Scripting/Development Trap for Data Migrations

When first faced with an enterprise data migration project some of the complexities can be well hidden, making the project appear quite straightforward - when this may be far from the truth.

For example, one would think that migrating from one instance of an IT service management (ITSM) application, such as ServiceNow, to a more up-to-date instance of the same application would be simple enough. But if the data structures have changed significantly between the old version and the new, or the old system has extensive customizations, a project team that hasn’t been made aware of the challenges might find itself stuck between the proverbial “rock and a hard place.”

How to Avoid The Common Do It Yourself Data Migration Mistakes

When planning an application data migration, especially a migration from one instance to another on the same vendor platform, many organizations first impulse is to take the “do-it-yourself” (DIY) approach. This is understandable, after all, how difficult can it be to move the data?

Most such organizations learn the hard way that a DIY migration can be much more difficult than expected. In this article, we discuss some of the reasons why DIY migrations from one instance to another can often lead to failed projects or large time and cost overruns.

Planning a ServiceNow Migration? Don’t Forget These Technical Considerations

By any measure, ServiceNow is among the most popular IT service management (ITSM) tools available today. Organizations worldwide have relied on ServiceNow to manage every aspect of their ITSM, from day-to-day helpdesk operations to problem management, change control, knowledge management, and more. Many organizations are long-time ServiceNow customers – some stretching back 10 years or more.

Staying Ahead of ServiceNow Migration Challenges

By their nature, most IT projects are difficult in many ways: Difficult to plan, difficult to fund, and difficult to execute. For some projects, it’s even hard to define what problem it is that you’re solving or the expected benefits of the project.

Those difficulties, among others, help explain why so many IT projects fall short of expectations or fail altogether. IT service management (ITSM) system migrations are no different, and many suffer the same maladies that other IT projects experience.

Data Replication vs. Data Back Up: What's the Difference?

Precision Bridge is a trusted partner in IT service management (ITSM), and in our years of operation, we’ve refined our solutions for data migration, archiving, replication and synchronization. One question we sometimes receive is “What about backups?”. This isn’t surprising, as backups are a bit easier to understand than data replication for those outside the IT world. 

In this article, we'll explore both the similarities and the differences between data replication and backup and how both can benefit your business.

Data Replication Challenge # 2: Too Much Effort with Little ROI

Data Replication Challenge # 2: Too Much Effort with Little ROI

Few businesses these days take on any project without weighing the costs against the benefits or evaluating the return on investment (ROI). In this analysis, most organizations consider aspects such as level of effort and total cost of ownership, which includes startup costs and ongoing maintenance and support.

Taken together, these analyses can help a business understand whether a proposed project is worth the effort.

Data Replication Challenge #1: Overcoming High Costs

Data Replication Challenge #1: Overcoming High Costs

Among Sir Isaac Newton’s laws of motion is that an object at rest tends to remain at rest, and an object in motion tends to remain in motion, unless acted upon by an internal or external force. Physicists call this phenomenon inertia.

Organizations can experience inertia as well. Sometimes it takes a great deal of effort to get an organization to change course. Even when an organization recognizes the need to change, it can be difficult to overcome the organizational inertia to implement that change. Finances, office politics, fear of change, and other factors can all keep an organization on its current path, even if that path is not the best one.

Top 4 Data Replication Questions to Ask

Top 4 Data Replication Questions to Ask

Any CIO will tell you that data preservation is one of the organization’s highest priorities. Data that is corrupted, physically destroyed, or compromised in some other way can bring a company’s operations to a halt.

A business can suffer legal consequences, too, for failing to preserve data. Most countries have regulations that require certain types of data to be retained, sometimes for decades, even if it is no longer in active use, or is tied to a system that was retired long ago.

The Current State of Data Replication and Archiving

The Current State of Data Replication and Archiving

With business data changing every day, it makes sense that so many companies leverage ongoing data replication processes to keep information up-to-date, accessible, and accurate in case they need to access it.

Briefly, data replication creates copies of selected application data in on-premise or cloud-based repositories. This includes processes for ongoing updates and data syncs. Compare this with data archiving, which creates copies of old or inactive application data and removes the original data from the source platform.

What’s the Difference Between Data Replication and Archiving, and Why It Matters

What’s the Difference Between Data Replication and Archiving, and Why It Matters

Data management strategy is always a hot topic in ITSM. In particular, we see an increased focus on data storage strategies and turning data handling from a must-have process into a point of serious competitive advantage. Replication and archiving strategies are always at the forefront of these discussions. For the uninitiated, what’s the difference between “replication” and “archiving,” and why should businesses care about the distinction?

Questions You Should Ask Before Your Next ServiceNow Migration

Questions You Should Ask Before Your Next ServiceNow Migration

Customizations to your IT service management (ITSM) platform are fantastic—right up until they aren’t.

ITSM enhancements to platforms like ServiceNow® enable new functionality and boost efficiency, but the paradox is that the more efficient they are, the quicker you’ll grow beyond their capabilities. Companies with highly built-out and customized ServiceNow instances will find that later, they need to migrate to a greenfield instance.

ServiceNow Instance Migration Mistake 4 – Taking a Big Bang Approach With Your Data

ServiceNow Instance Migration Mistake 4 – Taking a Big Bang Approach With Your Data

A common mistake companies make with their ServiceNow® data migrations is to assume that the entire elephant can be eaten in one bite.

Companies set up ServiceNow instances, get excited about the wealth of customizations available to them, and build out their instances into complex beasts that seem to suit their needs but present challenges when migration time rolls around.

How to Avoid Low-Level Development When Migrating ServiceNow Data

How to Avoid Low-Level Development When Migrating ServiceNow Data

Any way you look at it, a transition from one major business system to another is a daunting task. Even migrating between different instances of the same application can present major challenges.

In this case, many organizations are surprised to learn that different application instances have different data models, which means that they can’t simply copy the database from one to the other. For some field mappings, transformations are required, and some of them can be quite complex, especially when dealing with attachments, journal entries or workflow.

Data Migration by Manual Export and Import: Just Say No

Data Migration by Manual Export and Import: Just Say No

In the old days, a couple of years ago, migrating data from one business application to another usually went like this:

  1. A manual export from the source system to spreadsheets.

  2. A tedious manual manipulation of the spreadsheet data in place, tedious manual copying and pasting from the export spreadsheets to import template spreadsheets, or both.

  3. A manual import to the target system.

  4. A fervent hope that nothing broke.

  5. Repeating the process until it worked or the team gave up in exhaustion.

 Website Usage       Privacy Policy

Copyright 2015-2026 Service Management Integrations Limited. All Rights Reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States and/or other countries. SAP is the registered trademark of SAP SE.  BMC, Remedy, Helix and Remedyforce are registered trademarks of BMC Software Inc.  SQL Server, Sharepoint and associated logos are trademarks of Microsoft.  Oracle and Java are registered trademarks of Oracle and/or its affiliates. Salesforce is the trademark of Salesforce.com Inc. Precision Bridge is not offered, sponsored or endorsed by Salesforce. Jira is the registered trademark of Atlassian. RSA Archer is the registered trademark of RSA. Cherwell is the registered trademark of Cherwell Software LLC. Other names may be trademarks of their respective owners.