Repurposing content for multiple devices is often referred to as "porting." Typically with mobile content, such as Java games or applications, you need to port original content for different runtime engines. This adds a significant amount of time to your development cycle, and can add overall cost to creating the application in the end. One of the great aspects of Flash is the need to do less porting because the player is more ubiquitous and you really only end up concerned with device specs like screen sizes or UI considerations. Even then, you can sometimes make content stretch across more devices using some clever tricks.
When it comes to porting Flash content for different mobile handsets, there aren't that many factors you need to worry about. You might have more to think about if you were, say, going from content for the stand-alone player to making it run in the browser, but for this exercise you are taking content developed for Symbian S60 handsets and porting it to the Nokia Series 40 versions.
The main difference in this example, and in many cases of porting Flash to different handsets, is differences in screen size. Screen size varies mainly between manufacturers, but also between handset models: larger, smaller, wider—even portrait and landscape. Depending on the type of content you're creating, you can allow for these changes by creating your content on a Stage size that matches the minimum end-screen size, and then allow for the fact that content that appears off the Stage of that movie may be visible on other screen sizes (see Figure 1). Of course, your content will need to "bleed" off the Stage of the original movie to a large enough extent to be viewed by the largest screen size on which your content will be viewed.

Figure 1. Extending the content beyond the Stage dimensions of the smallest screen size to allow for when the content is viewed on larger screen sizes
In the case I'm describing, however, I took the opportunity to make some layout changes to the game screens to accommodate a larger screen size. With our game, we went from 176 x 208 pixels on the Nokia S60 to 240 x 320 pixels on the Nokia Series 40 (see Figure 2).

Figure 2. Making changes to the layout in order to make the look of your content fit the new size
Here's how you could attack the problem:
Resize and reposition backgrounds and game elements, and make changes to any ActionScript that was using absolute _x or _y values.
It's best if you don't use absolute Stage positions, if possible, just for this reason. For example, if there's a tree positioned on the Stage and you need the _x value of it, don't reference it by something like treeX = 75. Instead, use treeX = _level0.tree._x so that if you move the tree, the value of your variable moves with it.
This task was pretty easy because both handsets are Nokia devices, so the user interface on the handsets were nearly identical. Both handsets have soft keys and a common user experience. Things can get more involved if you move between makes and models of handsets.