10

I'm working with a web company that's approaching a point where it will likely need re-think the product as a V2 - due to outgrowing some of its V1 foundations and principles that have been built into virtually everything, from the data model to the user interfaces. For various reasons, this evolution might involve a migration from CakePHP (with which the V1 has been built) to Symfony or Zend.

I would like to ask for some experienced views on how people might have managed a transition like this for a website that has significant traffic and generates revenue. I don't want to open up a discussion on the pro's & con's of different PHP frameworks, or why this migration might be needed. Rather, I would be very interested in hearing whether there are some practical alternatives to essentially building a V2 from scratch alongside the V1 for a couple of months - and locking up precious coding time for the duration of this intense period. An example of such an alternative might be migrating an app in parts over a longer period of time.

I'd be grateful for any views from people who might have managed or been involved in such transitions.

Thanks in advance.

Tom
  • 391
  • 3
  • 10
  • If anyone somehow finds this, there is [a copy of this question on StackOverflow](https://stackoverflow.com/questions/4140001/migrating-from-one-php-framework-to-another) – ᴍᴇʜᴏᴠ Apr 21 '21 at 13:54

3 Answers3

7

Learn the new framework very well first, and make sure it is going to meet your needs, and that you really grok the paradigms of the new framework. You are going to have to throw out a lot of code, and that's ok. The important thing is that you are using the new framework the way it was meant to be used, taking full advantage of it's features, and not being tied into ways of thinking from your old framework. Don't try to use Zend "the CakePHP way"*

For example, when I moved to using MVC framework from previous non-MVC ones, I didn't really get how models, views, and controllers were supposed to work, and I wrote some terrible looking code because I didn't understand the new way of doing things. You'd be better off sticking with an inferior old framework than having a poorly written app on a better framework.

*I'm not familiar with either, so I don't know how similar/comparable they are.

GSto
  • 8,531
  • 7
  • 39
  • 59
  • +1 for `Don't try to use Zend "the CakePHP way` – Tim Post Nov 10 '10 at 03:23
  • y'know when people say '+1' they usually actually give the +1 by voting up the answer ;) – GSto Nov 10 '10 at 03:29
  • Sorry, internet hiccup. :) TCP over carrier pigeon here. – Tim Post Nov 10 '10 at 03:39
  • Thanks for the useful answer. I've dabbled in both Zend and CakePHP, and although I agree with your comment, I cannot as a matter of principle "accept" it when it's not hands-on experience speaking. – Tom Nov 11 '10 at 09:13
6

The first thing to consider is that rewriting a product from scratch is something you should never do. This is particularly true when the current version is already making you money. Basically, you're going to spend 6 months of time, just to get back to where you were 6 months ago. Only now, you've got more bugs (or at least, different bugs), re-introduced bugs that had already been fixed in the old code, and you're six months behind where you could've been at, had you been adding features to the old codebase.

CakePHP, Zend and Symphony are largely the same (i.e. they're all MVC-style frameworks on top of PHP), so I'm not sure what advantage you'd have moving from one to the other. There's certainly differences in feature set, but are they really worth setting yourself back all that time? For the amount of time you'd spend re-writing from scratch in Zend or whatever, could you spend the same amount of time adding the required features to Cake?

In my opinion, you'd be better off slowly refactoring your existing code over time, rather than starting completely from scratch with a new framework.

Of course, this is just my opinion. I know it's tempting to drop existing (ugly, old) code and start from scratch, but for established products that are already working, there is usually little to gain and a whole lot to lose.

Dean Harding
  • 19,871
  • 3
  • 51
  • 70
  • Exactly what I was thinking. No point in rewriting here, because there doesn't seem to be a strong case that it's going to be an economical decision. – EricBoersma Nov 10 '10 at 14:52
2

If this is a commercial application that's your company's business, you may be better off going without a 3rd party framework entirely. Then when time for v3 comes around, you wont be facing this same problem again. And you'll never be in a situation where you have to keep adjusting your code in response to updates to the framework. Frameworks are great for getting things up and running quickly, but if this is something a) core to your business and b) maintained over the long term, the value of the framework diminishes.

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
  • 1
    Thanks - Useful perspective, although frameworks make life easier with regard to so many things that it's hard to entertain the idea of not using them. They can also be customised and don't always need to be updated unless there's a real need to do so (e.g. security vulnerabilities, lack of support for X, etc). Accepting this answer as it's really about a "solution" rather than trying to address why the framework switch might be needed. – Tom Nov 11 '10 at 09:04
  • 1
    This answer isn't a solution at all. – James Feb 07 '16 at 20:29