My current company is product based, with an application started 7 years ago but never rewritten, a lot of garbage piled up. Right now, the management decided it's time to rewrite and after a little research we decided to stick to Django and Angular. The issue is that right now there are 12+ developers with experience in PHP and jQuery 1.3.

What would you consider a good strategy for the whole team to switch technologies? Everyone has to learn and of course, quality is expected.

Also, a part of the team would have to support the old application. Which are the best criteria to choose those? Personal option?

  • 4
    If you have 12+ developers with experience in PHP and jQuery (and from the sound of it, those developers have little to no experience with Django and Angular), why do you think that changing technologies (especially to one where people don't have experience) will result in a quality product?
    – Thomas Owens
    Commented Aug 28, 2017 at 19:13
  • @ThomasOwens I am not sure, to be honest. I came in the company after the decision was made. From what I understood was a decision made only from the perspective of choosing the most appropriate tools. There are 2-3 guys with experience in Python but more on the DevOps area, and not very familiar with the business logic of the app. I understand that you would've valued more the resources rather than the tools? Commented Aug 28, 2017 at 19:34

6 Answers 6


Don't do this.

Speaking as a developer, this sounds great. We get to rewrite that horrible old spaghetti code from scratch! We get to paid to learn a new language! There's a mandate for quality, so we can actually get the time needed to write good code!

...Oh, and there's the fact that this project will take a year or five. Speaking from a business perspective... not so great.

Of course, in reality, there's no way management will accept a realistic timeline for such a project. Instead, they'll insist on an unrealistic timeline. Put another way, they will insist (indirectly) on lowering quality. Which will end up with your developers spending a lot of time replacing legacy, presumably working spaghetti code with shiny, new, possibly not-working spaghetti code.

From your comment:

From what I understood was a decision made only from the perspective of choosing the most appropriate tools.

The 'most appropriate tools' are the tools used and understood by the majority of the Team. Adding a new tool to your toolbox is admirable... but it's a non-trivial undertaking. And, consequentially, it has a chance of failure (whether you define failure as time needed to learn or quality of code developed while learning, etc.)

Adding a new tool for the sake of expanding horizons: Good.

Adding a new tool as a dependency for an important project's success: Bad.

If you do really, truly have no choice but to rewrite an entire system in an entirely new language, then your best chance is to hire someone already experienced in that language. Or multiple someones. And you can't just point them at the problem and say 'go', either. Their job would be two-fold: to ensure quality of the product, and to disseminate their knowledge into the rest of the team.

Regardless, it'll be expensive and time-consuming.

Also, a part of the team would have to support the old application. Which are the best criteria to choose those? Personal option?

This seems to me like it should be a separate question, but I'll answer it here anyway. The best option is probably to do a rotation. If you rotate the people, then everyone gets some time to support/maintain the old application, so they all gain familiarity with it. If you don't rotate the people... then you'll likely have trouble keeping the ones stuck doing nonstop maintenance from quitting.

  • 1
    I agree that it may too big of a challenge after all. I thought of possible solutions like bringing experts of the particular technologies, start with a proof of concept in the beginning maybe with the most experienced developers, so that those at their time could lead other colleagues. But I never heard someone taking that step so he would tell from experience. Commented Aug 28, 2017 at 21:04
  • Thanks also for responding to the second question. My concern is that the application is quite big. I don't know if it would be too much of a burden for someone to be efficient in both contexts. Maybe specialized team per module, and within the team work on the same module on both old and new app. Commented Aug 28, 2017 at 21:11
  • 1
    We cannot equate tech stacks with tools. Architecture and tech stacks allow business to grow, become efficient, provide better services or a combination of all three and more. Tech companies that do not evolve their code bases die out, eventually.
    – Muhammad
    Commented Aug 28, 2017 at 21:14
  • 1
    @Muhammad While I agree that evolution is good/eventually necessary, I still don't think it's a good idea to combine the learning of a new stack/architecture with a large, important project. Like I said; adding it for the sake of expanding horizons is a good thing. But it's generally best to try to stick to one major innovation per project. And a wholesale rewrite is a major innovation in and of itself. It would make more sense, imo, to try out the new architecture/stack on a new, smaller project first.
    – Sarov
    Commented Aug 28, 2017 at 21:16
  • 1
    @Sarov, I agree. About trying out a smaller project first, a microservice based architecture, by definition, will allow that to happen. Organizations around the world are rebuilding their products this way. The project may still fail, of course.
    – Muhammad
    Commented Aug 28, 2017 at 21:26

The technology part of this question is not relevant to the problem. If the company has decided to make a change, then change is what you need to do. This also assumes that the case for change included a deep understanding of the gaps you have in your organization, i.e., technology knowledge and capability, and the costs and risks associated with closing these gaps. It further assumes the benefit to the organization by going through this change exceeds all the costs and risks.

You have a change project you need to define. You know your "as is" and you know the "to be". You need to identify what needs to occur in terms of training, replacing, and adopting the knowledge, skills, and abilities to change your product using the new technology, i.e., close the gaps between the as is and the to be. So the strategy you are looking for is to stand up a change project, get your funding, building your plans, define success, kick it off, and go.

Some of the investment in this project ought to be in the way of incentives and bonuses for those who adopt this change and work hard to both learn as well as maintain the existing product. This also means you need to get tough and remove and replace resistors to this change. Yes, you can expect some morale issues. Changes cause this all the time. Mitigate it the best you can but expect issues and degraded performance for awhile. The plus side to this is your people get to learn a new skill on the company's dime. That's pretty huge.

Good luck.

  • +1 for supporting the company's decision to change :)
    – Muhammad
    Commented Aug 28, 2017 at 21:16
  • Pretty huge indeed. I battled myself in the past even of adopting even small technologies. I think what makes reluctant a little is the fear of how those gaps can be properly closed. Should be hiring experts, invest in training for all the employees or just the best of them, creating a proof of concept first or starting with a subdomain of the application etc. Commented Aug 28, 2017 at 21:24
  • Also, I am not experienced in managing role but I was surprised by the decision to remove resistors. Isn't there a change that may act as a safety belt/gatekeepers? Or do you think they are just slowing down the process? Commented Aug 28, 2017 at 21:28

Below are some suggestions you may follow:

  1. First of all communicate to upper management the high learning curve costs involved (time and money).

  2. Perform specialized trainings. Hire trainers that know well both technologies so that they can map concepts from old to new technologies, this will improve learning.

  3. Parallel to step 2, assign to developers a simple project that will apply all concepts learned during training. The code will be thrown away when finished. This will reduce developers learning anxiety.

  4. Hire a temporary or permanent expert (5+ years) on the new technologies. The expert will help the team establish the architecture and the development environment. Will also promote best practices and mentor existing developers.

  5. (optional) Peer reviews and pair programming are good tools for promoting learning in a team.


This is quite a sticky situation. Firstly, you say the "management decided". This isn't ideal and the decision should have been made by the team, without the management's involvement whatsoever.

Since you mentioned Django, I am guessing the product needs to be rebuilt using a service oriented architecture. Aren't there PHP frameworks to help with this?

I have worked with Angular as well as jQuery knowing one won't help at well when switching to the other. Same goes for PHP and Python (Django), of course.

Having said that, I have been part of small teams, twice, where we went with completely new technology stacks. I was a developer the first time around.

What worked really well both times are:

  • Always insist on delivering functionality. Stick writing user stories. Developers grow in confidence when they build real stuff. Business people are happier when they see working software.
  • In the first few sprints, do not add more than 1 or 2 user stories. This will give the team enough room to learn on the job whilst solving real problems.
  • Keep the management at bay for the first 3 sprints at least. This means, forget about estimates whatsoever. In my second project when I was the Scrum Master, I told the management to ask about estimates and forecasts after three months as the developers are still training. Later, after 3 months, we showed them working software and exceeded all their expectations :).
  • Insist on a mature "definition of done" if your team is experience in general and only new to the technology stack. This goes hand in hand with the points above.

Disclaimer: The above points are from Agile/Scrum world.

With regards to the old application, I would really split the team so one works on building the new stuff, another that holds the fort. This will allow focus and minimize waste from "context switching. You should handle this tactfully though; find the right persons for each time, promise the team holding the fort that they will be amply trained on the new tech once time comes, etc.

Hope this helps.

  • 1
    Management decided I think because a lot of experienced people it seems that abandoned the team because of the application itself, day-to-day tasks that consists in maintenance and escalating bugs (patching one created new ones). Commented Aug 28, 2017 at 20:53
  • As for splitting the team, I agree that context switching would be too expensive. But I still don't know what would feel as a fair trade off. Just promising them that a better day will come without a clear horizon doesn't feel satisfying I guess. Commented Aug 28, 2017 at 20:56
  • I have to say I am really impressed that you managed to get the management away for 3 months. I don't know if it's the maturity/experience of the management or skills of scrum master, but it does sound a nice environment in which to start. Commented Aug 28, 2017 at 20:58
  • 1
    Fair comments but: Why did experienced people leave instead of changing the system themselves? Were they empowered enough? As for splitting the team, openly discuss it with your team or check with them individually. Every team has members who want change and others who want the status quo. The split might already be there? As for the management, don't confuse "keeping at bay" with keeping the dark. I reported lots of progress transparently. Its more about asking them to not ask for estimates and deadlines and trust the team to learn the new stack and show results in due course.
    – Muhammad
    Commented Aug 28, 2017 at 21:11

I have also encountered to this issue especially when technologies of web / app development changes and improves much more than before. To be honest, I work on Swift 3 iOS app for project management tools while learning react + meteor anew. Split the time frame per day into two or three sections :

Develop existing one / learning new tech. / study the business use of new tech.

If learning the new tech. can reduce your current development by more than half of required time, go learn anew. Principle underlying is more or less the same.

Expect there has a time lag for teammates to master techs. anew. as well as maintaining good progress of current development. It takes times when new tech. come across to new methodology. So fas as I know, taking react native/ angular JS as an example, the syntax and methodology is much similar to html + css + js. Good luck mates.


From the architecture point of view, if you have a legacy project then you have to do one of three choices, either to refactor the code, reuse some components or rewrite.

From business point of view, the technology does not matter as long as the project achieves the expected goals.

The best way is to do a smart rewrite; this means to rewrite module by module in php in the same application. You have an expert team in php and they are doing well, then what makes you change the language?

This will create many risks in terms of time, quality, security and many other things.

If you have to do the change then smart rewrite is your best option.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.