Monstrous migration from 1.2.5 to php7.2

Hi all,

I’ve got the humongous task of upgrading a relatively big app from version 1.2.5 to something that works with php7.2. :open_mouth:
From what I’ve seen, it looks like I need to upgrade to 2.10 or 3.5+ … which is a big Big BIG task. :roll_eyes:

I’m pretty sure I’ll need to manually migrate to 1.3 then 2.0 manually (maybe 2.1) – going to be fun --, but then I’m not so sure what’s the best way to move forward. I know there are migrations tools for 2.x & 3.x out there, but I’ve never used them. So what do you guys recommend ? :thinking:

  • I’ve read old articles mentioning 2.1 as a “big step”. Should I manually go to 2.1 ?
  • Do I need to go through all the 2.X migration one by one till I reach 2.10 ? or can I skip “easy-to-migrate” versions and go straight from 2.10?
  • Should I try to move to 3+ asap on the way ? and if so which 2.X version is a good version to make the move from ?

I’m trying to 1) do the minimum amount of migrations to reduce dev time, 2) do enough migration to mitigate risks and bugs, 3) use migrations tools as much as possible to speed up teh process.

Happy to read any feedback or experiences you guys may have.

I know it’s old… very old… but nobody has anything ?

I upgraded my app from 1.3 to 3.x. It was months of work. But it’s got 85 tables and 38 controllers, so maybe bigger than what you’re looking at. Also, when I got to the 2.x to 3.x conversion, I made the decision to fully use the OO methods of the ORM instead of the backward-compatible array parameters method, so that added quite a bit to the timeline. Well worth it, IMO, but YMMV.

I do recall that at the time (3+ years ago), the upgrade scripts ran into some issues and didn’t cleanly rearrange the folder and file naming structure. Hopefully, that’s been cleaned up in the meantime. Just obviously make sure that you have a safe copy of things, in case you need to try again. :slight_smile:

I don’t remember the exact process I went through, but I know for sure that there was one upgrade from 1.3 to 2.x and another from 2.x to 3.x. Note that the upgrade scripts are extensible; if you have common patterns in your code, you may be able to use that ability to have it do some of the grunt work for you. I also remember that I had one version that I made by running all the upgrades, and another version that I made by baking everything (again, the bake templates can be edited), then ran a side-by-side merge to basically move all my custom functionality into the baked version, to improve overall consistency among methods and compliance with the latest best practices.

Best of luck to you!

Thanks for the insights Zuluru, that is helpful.
85tables, 38 controllers… I’m around that, if not a bit more :expressionless: and yes… I’m planning months of work too.

if you don’t mind, would you have any advice regarding the following:

Do you remember if any specific version/migration was difficult ?
Do you think I should try to move straight from 2.0 to 3.x or go through the minor updates in 2.x before making the switch to 3.x ?
What about the ctp files/templates ? Did you get significant issues with the views ?
Considering I’m looking for php7.2 support, do you think I’d rather go for version 2.10 or 3.6 ?

Thank you in advance

Sorry, no specific recollections that would help with most of your questions.

Stopping at 2.x will be less work, but then you’re on an end-of-life version and have to bite the bullet when you need to go to PHP 7.3. I think it’s likely less work overall to go to 3.6 (or 3.7, or 4.0 by the time you’re done…) now than to do everything required to get a 2.x version fully functional and then repeat to get to a 3.x version. And between middleware and the ORM and improved compatibility with third-party plugins/libraries, I really think 3.x is the way to go.

Two main problems that I had with templates were a) switching everything from array access to object access (which was largely optional, but I wanted to fully embrace the new way) and b) changes in the structure of accessing related data. For example, if you read a user and contain their profile, 1.x accesses user data like $user['User']['username'] while 3.x is $user['username'] or $user->username, and 1.x accesses profile data like $user['Profile']['first_name'] while 3.x is $user['profile']['first_name'] or $user->profile->first_name. Note the fact that the “User” level is gone for user data, and profile is now lower case. So that’s just a lot of manual edits. Much of it can be done with search-and-replace after the fact ($user['User'] pretty much always just gets replaced with $user, etc.), but still.

Be sure to look at