5 ways to proceed with migration now that Parse is done

Parse – a cloud mobile solution owned by Facebook – recently announced the shutting down of their services as of January 2017. This means three things.

Firstly, even the best services might not make it as a business. Parse (i.e. Facebook) has probably lost the war with Amazon and Google, even though it offered a great product for cheap, or even too cheap. Secondly, you should never assume that a third party backend solution will last forever. Thirdly, if you’re currently developing an app with Parse, you need to think about the transition to a different solution. Here are our tips on how to do that.

Don’t panic and check how deep your Parse integration is

Parse is – or rather was – great because it offered out of the box services, which almost all mobile apps need. Push notifications. Login/logout. Simple logic between users. Simple, highly configurable database. All of these functions are commodities and can be moved to other services or custom made backend quite easily. In most cases, Parse was used to serve such simple needs, so a transition shouldn’t be that painful.

You should only be concerned if you have a more complicated logic in your app or integrations between Parse and other third party services. Define features that are key from a user’s standpoint and are currently served by Parse.  Rank them from crucial to nice-to-have but not absolutely necessary. Create a diagram to see the big picture and start carrying out damage limitation.

Create a shortlist of similar solutions and review them

There are many mobile BaaS (backend as a service) alternatives for Parse. Amazon comes out as the  clear winner with its AWS and AWS Mobile Hub. Google has its own service called Firebase. They actually tweeted that it has their full support today (yeah, you can believe or not). Microsoft also offers a good solution in its Azure cloud. Additionally, we can recommend CloudKit or Cloudmine. You’ll find more Parse alternatives here.

I wouldn’t bet my life on any of these solutions today. I used to be a Parse evangelist, and clearly I was wrong.

It is up to you which solution you choose. We suggest that you pick a service which offers the three following characteristics:

• It needs to make your pain go away fast. If you used Parse because you didn’t want to be involved in backend coding/server maintenance and wanted to a have simple, user friendly panel, you ought to choose another BaaS.
• The service you pick must also have its Parse migration process ready/documented. Within the next few weeks automated migration tools will appear. Choose a service which offers a clear solution.
• You must believe that the service you rely on will stick around forever. Well, scratch that! Facebook closed Parse, so anything is possible. “Trustno1”.

Decide if you really want to stick to a cloud solution

First things first: using BaaS is a risky strategy for any product in the long-term. It’s business 101.

We recommend BaaS as a good solution for prototyping/MVP: you can ship your app fast and safe and not worry about backend developer/server code maintenance overhead. Crucial infrastructure and backend code should be owned and developed internally. That’s one of software development best practices and the Parse fiasco has proved its significance. It is even more important for products with already proven traction and install base.

You might also consider moving your current setup to your servers – Parse published a module which allows to do this. Remember, however, that this might potentially result in some problems in the future. Contact us if you’re not sure how to do this right.

The decision is yours to take. Your final choice will depend on what stage of product market fit you are currently at and what your long-term plans are. We strongly suggest to the assess the scope of migration before moving on with the process. Acting in a rush is bad in itself, but if you do it without consulting anyone, it’s even worse.

Do a code review

We believe that good code is a result of transparency, team efforts and great processes. For that reason, we incorporated pair coding and automated tests as part of our workflow. On top of this, we carry out code reviews, both for internal and external projects.

We suggest you do to the same with your project. Doing code review not only gives you insights into what’s wrong with the app, but also allows you to see the things from a different viewpoint. In the case of the Parse fiasco, it will also help you with the decision process: Should I migrate to an open source Parse server? Should I rather choose other BaaS? Do I need to refactor everything? How much dependencies are there and how harmful will the process be? These are the crucial questions that you need to answer.

Currently, we are carrying out such reviews for our Parse projects – both internally and for our clients – to assess the damage and make well thought out decisions about next steps.

Migrate it, slow and easy

Let’s recap. First, you need take a deep breath and relax. It is going to happen, whether you like it or not. Over the seven years of software development we’ve witnessed dozens of cloud services go out business. We’ve always managed to switch or refactor in time without any major difficulties (make no mistake, however, smaller problems will occur!). Just don’t forget about carrying out a thorough QA process during and after the migration. The good news is you have 12 months to do this, as Parse will be switched off in January 2017.

How can you prevent such problems in the future? It’s perfectly normal and justifiable to use BaaS or other third party software, so don’t be afraid to do this. Yet, you need to ensure that you abstract out the dependency on such services.

➤ This post originally appeared on Netguru

Read next: Facebook’s Parse may be shutting down, but that means it can grow bigger than ever