<p>I have a large codebase that targetted Flash 7, with a <em>lot</em> of AS2 classes.  I'm hoping that I'll be able to use Flex for any new projects, but a lot of new stuff in our roadmap is additions to the old code.</p>

<p>The syntax for AS2 and AS3 is generally the same, so I'm starting to wonder how hard it would be to port the current codebase to Flex/AS3.  I know all the UI-related stuff would be iffy (currently the UI is generated at runtime with a lot of createEmptyMovieClip() and attachMovie() stuff), but the UI and controller/model stuff is mostly separated.</p>

<p>Has anyone tried porting a large codebase of AS2 code to AS3?  How difficult is it?  What kinds of pitfalls did you run into?  Any recommendations for approaches to doing this kind of project?</p>

Some notable problems I saw when attempting to convert a large number of AS2 classes to AS3:
Package naming
```
```
class your.package.YourClass
{
}
```
```
becomes
```
```
package your.package
{
    class YourClass
    {
    }
}
```
```
Imports are required
You must explicitly import any outside classes used -- referring to them by their fully qualified name is no longer enough.
Interface methods can't be labelled 'public'
This makes total sense, but AS2 will let you do it so if you have any they'll need to be removed.
Explicit 'override' keyword
Any functions that override a parent class function must be declared with the
override
keyword, much like C#.  Along the same lines, if you have interfaces that extend other interfaces and redeclare functions, those overrides must be removed (again, as with
public,
this notation didn't make sense anyway but AS2 let you do it).
All the Flash builtin stuff changed
You alluded to this above, but it's now
flash.display.MovieClip
instead of just
MovieClip,
for example.  There are a lot of specifics in this category, and I didn't get far enough to find them all, but there's going to be a lot of annoyance here.
Conclusion
I didn't get to work on this conversion to the point of success, but I was able in a matter of hours to write a quick C# tool that handled every aspect of this except the
override
keyword.  Automating the imports can be tricky -- in my case the packages we use all start with a few root-level packages so they're easy to detect.