Basically, the galaxy as you see it in the game is a procedurally generated galaxy melded with a star catalogue with some additional manual tweaking held within a database.
You, as a player have a database entry holding your game state. This will include which systems you've scanned and which objects within those systems that you've scanned. This allows the game to determine if it can show you the details it already holds within its database.
Currently this is all held on computers managed by Frontier, along with trade authentication servers an economics simulator and something to drive events and create the bulletin boards items on stations. Basically, a large database with a number of applications manipulating the data.
In an offline version of this it would have to be simplified so that there was no economics simulator, or at least a simpler one only affecting systems close to the player. Similarly a smaller and simpler event generator would be required. It's quite possible that a smaller number of star systems would have to be within the database too, though probably still a large enough radius that hardly anyone would reach the edge. It's also likely that "special items" and secrets would need to be changed so as to not spoil the on-line game through hackers extracting the data. Other parts of the system would be able to be simplified as there would be no need to run a trade authorisation step or have any of the network code overhead, merely creating NPCs in your "instance" as the client would in the case of you creating a new on-line instance where you were the first person in a location.
Now, a great deal of this code could be extracted from the various parts of the servers and integrated together, but it would be a lot of work. It would also create a new code base which would need to be maintained. If the off-line mode had to deal with later updates, such as planetary landing, then the production overhead could almost double relative to on-line only as each change to the server code would need to be back-ported to the off-line version of the code. You could also have to write database migration code to run on the client, which could be tricky. Oh, and then there's all this extra code to debug.
So, as you can see, Michael wasn't lying when he said that it was a lot of work.
