What if I don’t migrate my parse db until April 28th?

What if I don’t migrate my parse db until April 28th?

Parse announced about their shut down on January 28th. With this, they also released a database migration tool that lets you migrate data from your Parse app to any MongoDB database. They said the Parse API would continue to operate as usual based on the new database. It made sure the migration could happen without downtime.

What would I be able to do by migrating?


By migrating your database, you will be able to:

  • backup your entire database periodically and on demand;
  • restore backups;
  • increase performance of queries (and thereby your app) by providing larger amounts of dedicated processing power and memory to your database;
  • eliminate the risk of another app impacting the performance of your app’s queries;
  • gain raw access to your application’s data;
  • modify, add, or fine-tune indexes on your most popular or complex queries;


What happens if the Parse user don’t migrate the database until April 28th?


As suggested by Parse team, 28th April is the deadline to migrate the data from Parse. Parse team plans to address the issues reported by the customers that initiate the database migration process before April 28. After that, they intend to focus on providing support to the developers who would want to migrate their apps to Parse Server.


If you do not migrate your database by April 28, the Parse team would assume you do not consider the app’s migration to be a high priority. Traffic to your app may be de-prioritized as they shift their focus to serving production apps that are being migrated according to their recommended schedule, according to which July 28, 2016, is the deadline to finish setting up your hosted Parse Server and release a new app pointing to it.


How does data migration work?


Currently, the client gets connected to Database hosted on Parse with Parse API. Migration necessarily means you will have to transfer your entire database from Parse.com Hosted DB to another Hosted MongoDB. Then Parse.com will automatically point your Parse API to new Hosted MongoDB. It allows Client to interact with New Hosted MongoDB via Parse API.


Building a custom importer that can import data from Parse to local MongoDB or use programs like ngrok to expose your mongo port to the outside are some of the methods developers have tried to import data. But these methods are not as easy as they look. Instead, using the standard migration process with an internet accessible mongo installation is recommended.


New app version

How can you migrate data?


To get started with Parse migration, you will need to migrate data to a hosted MongoDB. Here, you need to use your self-hosted database, one of the Databases hosting providers or a full Parse hosting provider(database and Parse Server) such as back4app.


NOTE: If this is your first time with setting up a production MongoDB instance, we will recommend using a full Parse hosting provider. These companies provide a fully managed MongoDB instances with security, auto-scaling mechanisms and totally integrated to a Parse Server instance. In fact, you can use back4app which is the closest provider to Parse.com and has made sure that best practices used by Parse like Mongo Rocks are all implemented.


You need to Take care of following things while setup a self-hosted MongoDB instance in a parse migration process.


  1. Size your MongoDB at least 10x. Due to data being compressed in the hosted Parse database, you need to size your Mongo at least 10X the amount of data storage you are using currently.
  2. Set failIndexKeyTooLong=false Because MongoDB doesn’t allow index keys that are larger than 1024 bytes. If a write operation attempts to store a value which is greater than 1024 bytes in size to a field that has been indexed, it can result in error. Due to the way that Parse dynamically indexes collections based on query traffic, Parse has indexed some fields with values greater than 1024 bytes. To avoid random write errors from occurring, we configured “failIndexKeyTooLong=false” on Parse databases, and accept the write even if the field is indexed. Because of this, data with fields larger than 1024 bytes will appear as “missing” based on which index is selected by the MongoDB, query planner. Users who are migrating their data will only need to configure failIndexKeyTooLong parameter if they have indexed fields greater than 1024 bytes in size and had collections more than 1 million docs. For apps which are smaller, Parse will automatically clean up offending indexes during the parse migration. Larger apps should follow this procedure. You need to configure failIndexKeyTooLong back to true after the parse migration is completed.
  3. Latency between Parse and self-hosted MongoDB should not be more than 20ms. Our recommendation will be to host your MongoDB on a hosting service like back4app which has data centers based in the US East geographic region.
  4. If you are planning to host your production database in a different geographic area, do so after first migrating your data into the self-hosted MongoDB and out of Parse, in US East.
  5. To minimize latency, plan to host your Parse Server in the same geographic region
  6. Once MongoDB is set up, note the Mongo connection URL. Use the database migration tool for transferring your data (you can find it in the new Parse.com Dashboard under App Settings →General → Migrate to an external database). Make sure that the user in the connection string has admin privileges because the migration tool will be setting some parameters automatically during the process. Use Parse Migration Wizard at back{4}app to make things work easily.
  7. Snapshot: The database migration tool will first take a snapshot of your existing data and then transfers it to your Mongo database.
  8. Sync Next, it will pause to allow manual verification, while continuing to keep things in sync with writes that are coming in from your live app. While you are at this stage, your app will continue to read and write from your Parse hosted database.
  9. How to test the hosted database service?


It is advised not to commit your DB migration before testing.
Steps to be followed are: Verify if your app is working correctly because now it is pointing to a migrated
Then verify the data using Parse dashboard or raw data. Connect to your Mongo instance and browse through the collections in the new database created. Check the collection counts and do a few spot checks to make sure that your data was migrated successfully.


You may stop the migration and try again as many times as you need to (until the time you click on Finalize). The tool will keep things in sync for up to 24 hours after the parse migration started. Once you’re satisfied with the database migration, you can finalize the transfer in the migration box, and now your app is now using the new MongoDB instance. Here, your app is hitting api.parse.com, but it is using your MongoDB instance. You need to administer over your database instance by yourself, including maintaining indexes and scaling up.


You can elect to skip migrating your data and test the functionality of your Parse Server hosted app with an empty database. You can also migrate your data sometimes later.


Should I host my database?


One of the main reasons many developers chose Parse was because they didn’t want to setup and maintain a server. Considering this, and along with the fact that some custom work may be needed to completely migrate to Parse Server, another SaaS would be a thinkable solution. Even if you have you have hosted your database at present, by migrating it to another SaaS you would save a lot of time managing your servers and setting up the environments.


SaaS platforms are perfect for MVPs, rapid prototyping, personal projects, and powering smaller features of larger products. If your application needs to be built to scale, is mission critical, and continues to evolve with custom needs, it may be a better business strategy to build your backend. This way you maintain complete control and can leverage it as a competitive advantage.


Having said that there are also some great enterprise-grade platforms available that make this task easier too. These can be leveraged not only for cloud deployment but also to give you portability options.


Can you reverse the DB migration?


MongoDB is a JSON-style data store. The documents stored in the database can have varying sets of fields, with different types for each field. The database does have some structure. The system namespace contains explicit lists of our collections and indexes. Collections may be implicitly or explicitly created while indexes are explicitly declared (except for predefined _id index).


One of the great benefits of these dynamic objects is that schema migrations become very easy. With a traditional RDBMS, releases of code might contain data migration scripts. Further, each release should have a reverse migration script in case a rollback is necessary.


Also, if you are not happy with the database hosting provider, all you need to do is copy your data and point it to a new URI using Parse Dashboard.


How is Parse Hosting service different from Other BaaS and Platform hosting services?


A Backend as a Service couples a basic data store with expressive user provisioning and authentication tools. A BaaS that is optimized for mobile is called Mobile BaaS or MBaaS. The best use case for a BaaS is when data will only reside on either the device or the browser and the BaaS itself, with nothing in between. A BaaS does not have any backend processing abilities, so it’s not a good fit for data crunching or processing events like handling a batch of daily claims.


A Platform as a Service is something where you would deploy entire application architecture. The full stack, from application code to database structure to backend workers, is deployed to your little slice of the cloud. That slice, at the infrastructure layer (networking and OS levels), is managed by the PaaS provider. So, for a developer, PaaS is a container that takes the code or configuration as input and emits the URL of the application.


But when you have used Parse all these days you would know how easy it was to develop and maintain apps. It would be probably a little uncomfortable to go for any of the above as they only provide a part of what Parse hosting service can provide you. Using different services for different tasks is not what you would want to buy when all of them are available in one place.


Yes! back4app is a Parse hosting service which provides you much more than just a database hosting service or a platform hosting service. If you have your app or API developed using Parse, you can just migrate your app to Back{4}app and forget about Parse getting shut down. In fact, with Back{4}app, you have landed your app in the best. Along with Cloud Code and the Parse JavaScript SDK, this lets you build rich web apps without any servers. It lets you develop a website without worrying about servers or scaling, whether you’re designing a landing page or building a rich web app.


If you already have an app running on Parse how would you migrate data?


If you move your data from Parse to another location i.e. Mongo or another PaaS provider, you will still need to update the client code if you wish to change the API. If you have a mobile app, and your end users don’t bother to update their app, then how do they connect to the new datasource (DB)?


You would need to build this migrate functionality into your client from the 1st public version to be sure to capture all users so that you can flip the switch. That’s a lot of work, and you have to write your wrapper for the Parse API or REST calls.


If your app is serving HTML from the server i.e. a PhoneGap app, with server side page rendering, then you are de-coupled from the app executable on the end users phone/tablet. MeteorJS has hot code push to solve this.


You could send a notification to all the old clients that need to update their mobile app, telling them to update, and shutting down the Parse backend, but that’s not a great user experience. If they don’t have notifications turned ON you could code an alert or message to pop up based on you populating a field in the parse DB, poll to check it every few mins. But trying to migrate data without having a plan in place from the get-go is pretty much horrible.


Hope these answers to the questions that usually haunt the developers helps to understand and analyze the need to migrate data from Parse and make an appropriate arrangement to host the database. You can check out the easiest way of migrating your database using the Parse Migration Wizard at back4app. It allows you to migrate your data from Parse quickly, and since back4app is built on Parse Open Source, it is rather easier for you to migrate your app as you would need minimal code changes. Also, back4app provides almost all the features that were present in Parse giving you a feel that “Parse is still alive here”.


What are the benefits of migrating my database?

Here are the compelling reasons why migrating your database is preferable:

-You would be able backup your database and restore it completely or on demand. 
-It will increase queries performance by offering enhanced dedicated memory and processing power. 
-Eliminate the risk of any other application’s impact on your performance. 
-Get access to your app data with more freedom. 
-Add, modify or fine-tune indexes on your queries.

What will happen to my application if I don’t migrate?

If you are not going to migrate till Parse deadline, then traffic to your application will be deprioritized. As per parse report they are going to focus more on the production apps which will migrate as per their recommended schedule.

Is there any parse hosting solution which can offer you more than just database hosting?

Yes, Back4app is one of the most amazing parse hosting solutions which is much more than just a hosting solution. If you have an API or app developed with Parse you can migrate your application to back4app and just forget about the shut-down of parse afterwards. 

Leave a reply

Your email address will not be published.