Migrating from a GPS tracking platform? How to approach this?

By Fernando Perez Maier CRO & Co-Founder of RedGPS

Many years ago, before founding RedGPS, I worked for an Argentine company that was a Microsoft partner at the time. My position was as an Infrastructure Consultant. The department was dedicated to implementing and/or migrating Microsoft products in corporate environments.

In most cases, our clients were well-known and prestigious companies such as oil companies, telecommunications companies, chemical companies, etc. Therefore, the projects were often significant. I remember that time with great joy because I learned a lot and made many friends, as I spent months in the clients' offices.

Many times, we had to do new implementations, but I was fascinated by the challenge of migrations. In some cases, the goal was to migrate from Windows 2000 to Windows XP all the workstations of a company, or migrate the mail server of a corporation or server management and monitoring solutions.

In any migration project, there are three key moments:

• The first moment always took place in a meeting room where the table seemed endless because of its length. I had to defend the migration plan to the company's IT heavyweights. My task was to demonstrate that there were no loose ends that could lead to economic losses for the company, and their task was to find flaws in my plan. The meetings ended up being a kind of ping pong until the last doubt was resolved.  

• The second moment took place in front of a server or workstation, or sometimes inside a data center. At this moment, the switch or the start of the migration took place. 

• The third moment was to analyze and verify the success of the process, or deal with the unexpected and decide whether to proceed or perform a rollback until each problem is resolved.

In this part, planning, experience, and plan design came into play in the eyes of stakeholders. 

In those years, all the projects I participated in were successful. We didn't have any major problems for the company, and the reasons were as follows:

1. Experience and Training: We represented Microsoft, and this software giant made sure that the personnel in charge were the right ones, up to date with certifications, and more.
   
   
2. Contingency Plan: In the project design, we always had a Plan B for all the expected scenarios and a Plan C for the unexpected ones.
   
   
3. Change Management: The key to ensuring the adoption and success of the new project is change management. Change can be a painful process that can have a far-reaching impact on an organization and the people who work for it. For this reason, work is done to demonstrate the scope of the change to operators, IT administrators of the company, as well as to end users: the office workers who are the critical mass. Different areas sometimes had to be trained differently. In short, managing the expectations of each stakeholder is of great importance.

The valuable thing about this story is that migrations did not always go as planned at the beginning, sometimes expected problems or surprises arose that had to be dealt with. The key was that we had a contingency plan with rollbacks and walkarounds for each of the unforeseen events that could happen. I emphasize that we were very well-trained and certified in all these technologies from the beginning. 

So, to answer the initial question: I know that with proper planning, it is possible to migrate a GPS tracking platform in a company as in any other business without it being too stressful for any of the parties involved. 

Over the years, our technical team has perfected the onboarding processes to achieve the best customer experience for those migrating to our platform. 

How to Migrate a GPS Tracking Platform?

Migrating a platform is a challenge and a risk for any GPS tracking company. It is a process that many business owners have already gone through, and some have had to do it multiple times due to the years they have been working in the industry. At RedGPS, we have been involved in migrations of new customers for over 10 years, and to this day, we continue to improve the process. However, this does not mean that I recommend migrating all the time; my goal in this article is to help you define when to proceed with a migration, evaluate the cost it may entail for your company, and guide you through the process.

The following index will help you identify what you should consider:

1. Why Consider a Migration?
2. When to Migrate and When Not To?
3. How to Present It to Your Client?
4. Action Plan and Productive Pilot

1. Why Migrate from a GPS Tracking Platform?

The world is advancing, technologies are evolving, and fleets demand different or better services, which is the main reason for migrations: to remain competitive and deliver value to those who hire your services.

Previously, GPS tracking companies focused on security issues, such as installing a panic button. Now, in addition to continuing to do that, they have to collaborate with fleets in the digital transformation of businesses and the IoT world to provide processed information and KPIs on fleet productivity.

2. When to Migrate and When Not To?

If you are the leader of a GPS tracking company and you are reading this, I imagine you have doubts about whether a migration is what your business needs to grow. I'll get straight to the point and list the three reasons I recommend migrating:

• Outdated Platform: Your current platform has become outdated; there are many platforms that have become obsolete or discontinued. You receive complaints from your customers, they tell you they have found better solutions, and you need to make a change. 
  
  
• Stability Issues: The platform you are currently using experiences frequent outages or service interruptions that affect your customers and your business, whether the platform is in your data center, in the cloud, hybrid, or with an outsourced provider. If the platform goes down, look for a provider that guarantees, by contract, a service level agreement (SLA) that is greater than 99% (or in other words, it guarantees that the service will be available more than 99% of the time).
  
  
• After-Sales: If your technical department has a problem and needs to consult the platform's technical support, but it is not up to the technical level or does not provide responses in an acceptable time, this is a clear sign that a change is necessary.

In my opinion, these three points should not be negotiable in any way; they are foundations that should be in any GPS tracking business to be able to grow. 

On the other hand, there are scenarios where perhaps a complete migration is not warranted, but hiring a secondary platform to complement your current business:

• Professional Services: Your current platform lacks flexibility to meet your customers' specific needs. Let's say you have to respond to a tender, and you don't have enough support to answer the specifications or estimate the associated time and costs to comply with it.
  
  
• User Experience: Your current platform is not intuitive, agile, or does not provide a good user experience.
  
  
• Niche Solutions: Your current platform lacks solutions beyond basic tracking, and you need to provide more robust niche solutions that your provider refuses to develop.
  
  
• Cost: You have a very good platform but need to provide a lower-cost service, which is not feasible with your current platform.

3. How to Present It to Your Client?

This point is often the most worrying for GPS tracking entrepreneurs. Over the years, I have had to answer questions like these: How do I explain to my client that I'm changing the software overnight? For what reason? How will they take this news? Could I lose the client due to this change? How will this project impact my team? How much growth will I forego in the meantime? What costs will I have to face? And many more.

In short, there are many valid questions. The key point that will help you make the decision is to have your company's mission well defined and where you want to see your business in five or ten years. Based on this question, it is necessary to ask if the platform change aligns with your goal. This first point will help you decide if this strategic action will contribute to your business. 

Then, to talk to the client, we must be very clear about the reason for the migration, communicate the medium and long-term benefits, and how the migration process, training, and contingency plan will be. In other words, show your client why the change is for the better and that the risks are anticipated and limited. Evolving in our industry is necessary, and you know it. If a hesitant client does not want to do it, you can start migrating others; when the client in doubt sees the new software in action, they will understand the reason for the change.

Many times, you have to wait for contracts or tenders to finish in large companies to convince partners and/or investors to make the change. That's why, in this article, I explain how to do it without risks and with a flexible plan to move forward steadily. In the action plan that follows, I'll clear up certain doubts.

And regarding costs, it is assumed that you will have to incur a cost. But ATTENTION: it's very likely there could be consequences if you don't migrate. Both decisions will have a cost, and each scenario is different. You must consider that you'll have to allocate your time and your team to the migration process related to internal training on the use of the new software, customer training, new developments to be made, or migrating existing developments, GPS tracker stock for any unforeseen events, etc.

4. Action Plan

I'll list a series of questions for you to answer and build your action plan:

1. What would be best for my business?
2. What goals do I have in mind?
3. What should I improve?
4. What are my weaknesses?

And based on what was explained previously, I will help you answer another big question: Does my company need to migrate? Do I need to hire a complementary platform, or should I continue to invest in what I currently have to improve it?

In case you decide to improve what you currently have, whether it's a custom development or you are considering investing in your current provider, first, conduct a thorough analysis of who your provider is. Ensure they provide correct support and that the mission of that provider is aligned with your industry vision and your business.

Finally, if you have come to the conclusion that migration is what you need, from here on, I will begin to list the process, recommendations, and everything that our team typically executes.

a. Migration Plan

A well-executed migration demands never endangering the health of the business, so it must be well designed, tested, and executed. It's not a difficult task; all that's needed is a good checklist to ensure we don't forget anything and that all parties involved are aligned with the migration goals.

First, I recommend executing the viability and feasibility analysis stage:

1. Define which platform you will migrate to.
2. Check if the platform supports the GPS devices you currently have.
3. Get to know the technical team of the platform provider.
4. Test each of the equipment models and the linked sensors.
5. Internal evaluation of the platform.
6. Evaluation by the most important customers.

Once you have the green light from all parties, focus on technical issues to dimension the migration.

b. Survey

1. Number of assets to migrate
2. List of clients
3. Users, groups, permissions, alerts, notifications
4. Device makes and models
5. Connectivity
6. Data
7. Locations, geofences, routes, icons, reports, views, maintenance
8. Custom developments
9. Web services, repeaters
10. SMS gateway
11. Mobile apps

If a proper survey is conducted, it's possible that scenarios that were forgotten or not foreseen in the previously mentioned analysis stage may start to appear. This is good for further validation and scoping of tasks that need to be resolved before starting the migration. It's preferable to encounter these unexpected situations at this stage rather than during the actual migration.

c. Design of a GPS tracking company's migration

Years ago, vehicle migrations were done on the fly with little surveying, some basic data import, sending commands to reprogram the GPS tracker, and that's it, the client was migrated! 

We've had experiences with clients who take months to migrate, and others who migrate in days or even hours. It all depends on the circumstances; for example, we've had to migrate clients unexpectedly because they had another platform, which has been offline for several hours, and they urgently call us for an emergency migration. Forced migrations are not recommended at all; they cause a lot of stress for the end client, the integrator, and our technical team. However, we also understand that it's part of the business and it helps us grow as well. 

We find it amusing that our business development team pursues some important accounts for years, and because they prefer not to make significant changes and step out of their comfort zone, they choose not to. However, the tragedy is when they call us on a Saturday or Sunday morning in the middle of a family barbecue to urgently ask us to help them migrate everything at once, regardless of anything, because their platform has been down or experiencing interruptions in the last 2 or 3 days. 

Now, in a controlled and non-urgent scenario, we've created a series of tools and processes that allow migration with very low risk, and everyone can have a peaceful lunch on the weekend. This process is a creation of our technical team, which is always thinking about adding value and supporting GPS tracking companies that approach us. It consists of a simple loop that allows validation before migrating.

d. Checklist and Productive Pilot

1. Import data into the new platform.
2. Reprogram a GPS tracker of each model with their respective sensors to report to our platform in a lab environment. 
3. Validate that the GPS tracker works on both platforms simultaneously.
4. Repeat the first 3 steps with a real client. 
5. The client validates both platforms and tests the new platform for one or two months and confirms. 
6. Assets from the previous platform are deactivated. 
7. There you go, you've migrated your first client.

In the productive pilot, there's no need to migrate everything at once; you only take one client and a few assets, run tests, and progress as the client gives the green light. 

This same pilot is the key to continually iterate from client to client, and the integrator, meaning you or your technical team, have control and migrate as conditions become optimal. This way, small needs like reinforcing customer training or improving overlooked details come to light, eliminating any risks.

In summary, planning, surveying, and stakeholder expectations are very important, and, most importantly, conduct a productive pilot with each client. If you follow these steps, I assure you that your migration will be a success. 

I hope this article helps you with your platform migration. My intention was to make the article as generic as possible to be useful for migrations regardless of the destination platform. However, if you choose RedGPS as your new platform, you should know that, in addition to providing migration tools, we collaborate online minute by minute to address any needs or unexpected issues.

We understand the magnitude of a migration project for your business, which is why we put all our collaboration with training staff, Account Managers, and technical support to make you feel from the first impression that the change you made was the best choice.

You Might Also Be Interested In