Migrate Ember 1.7 to Ember 2.9

We have a quite large app building on top of Ember 1.7. There are quite a significant portion of the code is legacy and we want to refactor/re-architecture to get rid of. The goal is to be on the latest version of Ember (2.9 at this moment), leverage ember engine so later we can port portion of the app to other apps if required. This time is we don’t have a lot of request for new features and we have 6-8 weeks to invest in technology updates. Also during this time, we may be required to add some features to the existing app. Our developer(s) may get pulled to work on some other small projects for couple of weeks. We consider being on Ember 2.x is crucial. In 2017, we may not have the time to do the migration. We have 2 options at this moment:

  1. Dive with our head down rebuild the app with the latest ember which mean do the refactoring at the same time with migrating. If there are new features, we will add to the old app and migrate later.
  2. Refactor first, re-architecture on the 1.7 version of Ember, get rid of the legacy code we don’t want and migrate when we’re done with refactoring. If we need to add more features to the app, we can add during the refactoring process. When done with refactoring, we will freeze the app from new features.

The first approach is more risky, thing can go out of control because of refactoring and migration at the same time. But if things go well, it could be done in shorter time.

The later approach is much safer. If we run out of time at the end, we still have a better code base. And whenever we have time we can come back to do the migration. But it would takes longer since we will need to do another short of refactor when migrate to ember 2.x. And we may never have time for migration and forever get stuck with Ember 1.7.

We are trying to look for a third approach which is refactoring and migrating a smaller chunks of the app to ember engines or smaller ember apps. And inject these small engines/apps to the existing large legacy app. However, I could not find anywhere which mention we can use Ember 2.x inside an Ember 1.x app.

Any idea, suggestion, tips hint on that we can reach to our goals will be really appreciated. One more thing, the existing app using RequireJS.

Thank in advance. Vinh

There is a third hybrid approach. You can use a server render technology (RoR, etc) to split the app up into multiple apps. You migrate each of these slices one at a time. From the users perspective, this will be transparent as the app looks identical. Finally, when you are done with all of them, stitch them back together as engines.

Less risk than total rewrite, but essentially is a rewrire and probably take more time. But I would say it’ll get better chance with management approval.

1 Like

Due to Ember’s history, this isn’t likely to work easily. Ember has run as a global (although that the goal is for that to change). Theoretically you could dive into the internals to see about altering that for one of your apps but I doubt that would end well …

I’ve seen folks talk about having one app running as an iframe inside of another. It would be doable to have shell apps, but you may find that your time budget is a bit too restricted to both handle the shenanigans needed for that combined with rewriting part of your apps …

1 Like

Changes between 1.7 and 1.13 were huge… I would suggest to upgrade from 1.7 to 1.8 after to 1.9 … and each time fix the deprecations only… big changes between 1.11 … 1.12 and 1.13… deprecation messages drive your priorities and step by step you clean up your code… from 1.13 to 2.4 and after 2.8…

From 1.13, you can use almost all the new features, like Services, you can add Ember Data, you can migrate your View-s to Components… in that stage you can migrate your app from RequireJS to Ember CLI…

Acceptance test, integration test and unit test harness help a lot, so I would add more and more also, close to 100% code coverage is a safe goal, however in your case I would focus on acceptance tests mainly… :wink:

If your file structure and naming conventions don’t follow Ember-CLI structure, I would reorganize and rename files directly after 1.13 upgrade.

Maybe you already manage apps separately, it works with require.js, so actually you have a few independent app/page… and you have a few common file which shared between them… The common part can be migrated to Ember Addon… and the big separated sections can be independent Ember Apps… later you can merge them together with Ember Engine…


@ lightblade, @acorncom and @zoltan, your inputs are highly appreciated. Thank you very much for your help and contribution.

@ lightblade: use server render would not be a sound option for us since I will take a lot of efforts to set up and get familiar with the technology, my team is all front-end folks. It would take even long than the 2nd approach that we have.

@zoltan 's suggestion is pretty safe I guess but it sounds taking a long time since we have to go through many phrases of refactoring and migration.

I share the idea with @acorncom. My team can start with features of the app where it’s not likely required to change, rewrite those feature as Ember 2.8 engines. Build a wrapper app to host those engines. Then add iframe to the existing Ember 1.7 app to load the wrapper app.

To the user perspective, they wont be aware of the differences. To us, we can rewrite portion of the big app one by one, we can add new features when ever we need to and we can have total control of the process. The old parent app and the child new app can communicate via post message. And when we are done with migrate everything to engines and latest Ember, we’re then modify the wrapper app to entirely replace the old existing parent app.

Things we need to tackle:

  • Adjust development and deployment workflow to work with the new process
  • Communication between parent and child app can be frustrated
  • Ember engines concept is new, it’s quite difficult to seed help or looking for resource when we get stuck
  • Other unforeseen challenges ?

If everyone could help, please contribute your idea/suggestion to the using iframe path, is it good or bad? What other challenges we may face during down the road.

We’ve done some embedding of apps into a cohesive UI using iframes. We haven’t done it with 2 different versions of ember, but it seems doable. We have don’t it with ember at the top level and angular and knockout as apps in the iframe.

Essentially communication between parent and child is done via cross document messaging, things like communicating route changes, etc