As already pointed out by "900ss D." it can cause trouble if the 
update-code gets copied to RAM and deletes the old application during 
the update procedure. If update failes i.e. because of a power-failure 
the application code in flash and the update-code in RAM are lost and 
firmware has to be rewritten to flash using ohter channels (factory 
bootloader, JTAG...).

You might check the documentation how software-protection is 
implemented. Some target have limitations which flash-pages can be 
written from application code if protection. Even if it's possible 
disabling the protection temporarly might not be an option since this 
might open a security hole for a short time. Maybe there are also 
non-volatile settings or external pins to set the default start-address 
(I can not rememeber this for Stellaris devices. But maybe there are 
options like this.)

Possible appoaches:
(1)
- inital programming of the memory with the vector table at the start of 
flash and the update code (=bootloader) at the end of flash.
- the reset-address in the vector points to the update-code's 
reset/startup-routine
- the bootloader has its own vector-table to handle its interrupts and 
the first instructions of the update-code remap to this vector-table
- the update code tests for an update request. Maybe by waiting for a 
special package received over ethernet until a timeout of by checking if 
a key is pressed.
- if there is no update request the bootloader checks if there is a 
user-application in flash. This could be done by checking for a 
version-number or "magic-number" at a known memory address or simple by 
checking for empty flash
- if there is an update request the update code receives the flash-image 
and writes it to flash but changes the reset-vector address before 
writing the applications vector so the update-code is always started 
first. The reset address of the user-application gets stored at a known 
memory address, maybe in one of the reserved elements of the vector 
table.
- after update or after timout the bootloader sets the stack-pointers, 
remaps the vector-table to the default, reads the applications address 
from the known locations and finally jumps to it

The advantage of this approach is that there is no special memory layout 
needed for the user-application and no need to take care of remapping in 
the user-code. Everything "special" gets handled by the bootloader.

(2)
- bootloader including its vector-table gets installed at the beginning 
of the flash-memory
- bootloader always starts first, checks for update request as outlined 
above.
- user-application starts at a known address after the end of the 
bootloader-code.
- bootloader tests of update-request, receives new code, writes it to 
flash
- after update or if there is no update request the bootloader reads the 
reset-vector of the application from the known start-address, sets the 
stack-pointers and calls the user-applications reset-handler. Optionally 
the bootloader can already remap the vector-table address but this could 
be also done in the reset-handler of the user application
- the user-application needs to be linked to start at the known address. 
The address needs to be a valid postition for a vector-table (valid 
addresses/aligments should be listed in the documentation). For this 
minor modifcation are needed in the linker-script or special 
command-line options need to be passed to the linker

I have implemented both approaches successfully with STM32 devices where 
firmware updates get read from a SD-Card. So the basic concepts do work. 
But of cause TI/LMI Cortex M3 devices are different in terms of 
in-application-programming and there may be differences in handling the 
vector-table location/offset.

Hope this rather long post gives at least an idea.