For everyone with a Flex 3 project that wants to give Flex 4 some love; this post's for you.

It's been a long road. Lets just say that you've looked around alot... asked tons of questions... seen a lot of posts... and have finally decided that it's time to migrate.

There's a good guide by Joan Lafferty on the differences between Flex 3 and 4. Perspective and scope... still... are hard to grasp. How difficult is a migration really going to be?

This is a difficult question to answer without some kind of reference point or frame around what it is you're trying to migrate. We need a subject... something simple / practical... something familiar like ListBase.as? It's the bread and butter behind controls like List and DataGrid and should serve our purposes nicely. Giddyup!

Before we start, it's important to prepare mentally for a migration; consider the valsalva maneuver in weight lifting. Traversing the gaps between the known and the unknown will feel less treacherous with the right frame-of-mind.

"Walk to the edge of the light, and perhaps a few steps into the darkness, and you will find that the light will appear and move ahead of you."

President Harold B. Lee

Ready?

My first question was, "...are controls that implement the new ListBase.as interoperable with the old ones?" I put together a couple really basic samples and had no problems exchanging one for the other - they even work well side-by-side. So, interoperable? Maybe.

I then took a project that used custom item renderers and tried to compile with Spark List... and that's when things esploded. What's the deal?

If you do a side-by-side comparison of the two ListBase implementations, the 'gap' should be crystal clear. The changes from 3.2 to 4.x aren't trivial... [ cough ] 8,000 lines worth. So, if you've grown accustomed to using methods like indexToItemRenderer or itemToItemRenderer, interoperability is going to be a problem.

Gulp! Eight thousand lines? Yes. It's big... which means that you'll be spending a fair amount of time replacing deleted functions with static utility methods, subclassing and adding missing bits back in, or flat-out rewriting sections that won't compile. Using the compiler 'compatibility mode' may save you some headache but it isn't a long-term silver bullet.

To be frank, migration is probably going to be tough; Flex 4.x is young and large portions of the framework are still in flux. Flex 4.5 (Hero) promises to be the light at the end of the tunnel... patience is a virtue right? Sigh.

These kinds of tasks are so daunting; here are some line-items that can help you find calm in the chaos.

• SDK Source: The more you live-in / know about Flex frameworks the better
• Diff Often: Be conscious of deltas and keep your expectations realistic
• Interoperability: Don't expected it... if you get it, great - if you don't move on

What now? You're still going to migrate that app right? The only thing left to do - is to dig-in... there's no time like the present!