Support Topics Documentation Slack YouTube Blog

Migration from 3.0 to 4.0

(mike turner) #1

I have 3 apps on the backendless 3.0 cloud. How long will you continue to support 3.0 apps in the cloud before we need to migrate? As 4.0 isn’t backwards compatible there is quite a bit of work involved to convert all of the apps to 4.0 so would like an idea of how much time we may have to convert. Also, once we migrate an app to 4.0 it won’t work on the client side apps until the users update their apps to the latest version running 4.0 code so how would you recommend handling this situation? At first thought it would appear we would need to keep a 3.0 and a 4.0 version of each app in the backendless cloud until all clients had updated their mobile apps, but that would mean then having 2 sets of user data in the cloud which would be a messy solution.

(Mark Piller) #2

Hi Mike,

We will continue running the 3.x as long as there are customers on the paid plans there. We will be winding down free 3.x apps about 6 months after 4.0 goes into production.

As for your app, suppose you copy the data from 3.x to 4.0 and release a new version of the app. Do the users on 4.0 need to see changes made by the users on 3.x?


(mike turner) #3

Hi Mark, OK thanks, so I should have at least 6 months that’s some comfort.

With regards to my app then users on 4.0 do not need to see changes by the users on 3.x that is correct.

However we also have an admin website where owners of the apps can analyse and use the data used by the users of the app (eg. send push notifications to users) At the moment all that data is on the 3.x data tables. If we had some users on 4.0 and some on 3.x that data is going to be on data tables on 3.x and 4.0 and not in one place so we would need some sort of code to pull that data together which I can imagine would be a major headache! Can you think of an easier, better way?


(Mark Piller) #4

Hi Mike,

What about a solution where you add beforeCreate, beforeUpdate and beforeDelete event handlers in the 3.x app and replicate the changes into the 4.0 app? This way the data in the 4.0 app will always stay current and the app owners can work only with the 4.0 app.


(mike turner) #5

Hi Mark

Yes, that sounds a possible solution. I’ve not used the event handlers before. Do you have a help file on this you can point me too? I think I may also be interested in a quote from your team to do this for me if I run out of time. Would it be possible for them to give me an idea of price?



(Mark Piller) #6

Hi Mike,

You can read about event handlers at:

Yes, we can definitely provide a quote. Could you please send an email to and reference this topic?


(mike turner) #7

Hi Mark,

We are due to begin this process of moving an app from 3.0 to 5.0 and I will be in contact with sales as I may need some help with the event handlers as you mentioned in a previous (old!) reply.

This is quite a process for us as backendless 4.0 wasn’t fully compatible with version 3.0. My client is a little uneasy that if we move now to backendless 5.0 that we may have to do a similar exercise further down the road. Can you give any assurances that if we move to version 5.0 may we won’t have any compatibility issues in the near future when new versions of backendless are released?

The notification system in version 5.0 now looks amazing and this has been the incentive to upgrade. Nice work! especially being able to use the notification templates in the API. That looks really powerful.


(Mark Piller) #8

Hi Mike,

We do not anticipate any breaking changes with the planned releases in the foreseeable future. The changes from 3.x onward were needed to allow us to put a more scalable operational logic in place.


(mike turner) #9

Hi Mark, thanks a lot that is good news.

If I press the ‘copy your app to 4.0’ button on the console, I am presuming this will do that - copy the app to version 4 and keep the existing version 3.0 app untouched and fully functional as it is now.

I don’t need to panic if I press the button?!


(Mark Piller) #10

Hi Mike,

No, you do not need to panic. You will see a popup with instructions and a button to create an export archive.


(mike turner) #11

ok fab, thank you for clarifying that!

(mike turner) #12

I wonder do you have any sample/example code which would do this kind of thing you suggested for me to try?

What about a solution where you add beforeCreate, beforeUpdate and beforeDelete event handlers in the 3.x app and replicate the changes into the 4.0 app?

(Mark Piller) #13

I’m afraid we do not, however, it would be rather straight-forward. You would need to make an API call from the event handler in 3.x into your 5.x app. It can be a REST API call which creates an object when you call it from beforeCreate, updates an object when you call it from beforeUpdate and deletes from beforeDelete

(mike turner) #14

Hi Mark, sounds easy, but I am actually struggling with this! I might have to pay you to write some sample code at least. How can we proceed?

(Mark Piller) #15

Suppose the migration is finished and there are two apps now: one in 5.x and the other in 3.x. Each backend has its own app ID and API key (aka “secret key” in 3.x), which means you need to either have two versions of the client app or upgrade the existing client app to use the backend in 5.x. Which one is this going to be?

I’m trying to understand the external constraints to figure out if you even need the event handlers. Please help me out here.


(mike turner) #16

It is going to be the former - there will be two versions of the client app - one running version 3 and one running version 5. At least until all the users have updated the app to version 5, but that could be a while and until then we want the users of the version 3 app to still be able to login and see their loyalty points (it is basically a loyalty app)

We also have an accompanying website which currently talks to the backendless 3.0 version, but we are in control of this and this will be transitioned over to work with backendless 5.0 only. But of course if a user who is on the version 3.0 app gets loyaltys points added - we need this data to be moved across to the backendless 5.0 tables so that should they login to the website they will see those points, likewise the operators of the loyalty app scheme need to be able to see those points too as they will now be using the backendless 5.0 tables to see the data in their admin website.

Does this make sense? So long answer I think that event handlers are needed. In an ideal world if any data was changed in a table in the backendless 3.x app then this data gets created or updated on the backendless table 5.x table too. Like it is mirrored. Does this help you?

(Mark Piller) #17

Thanks, it makes it much clearer. I recommend getting the migration of the data done first, then we can revisit this topic. We can definitely help with the implementation. Please contact to get a quote for the professional services assistance.

(mike turner) #18

Yes thanks Mark, there was an error in the Migration - I have listed it on another topic. As you say lets get that done and then I will send you an email to get a quote. Depending on the figures I might just ask for some ‘starter’ code and then I can finish it off or something to keep price down. Thanks and have a good weekend!