There are multiple ways of doing it however, I personally don’t know the most efficient way for an LOD system however, I can give you details about them.
@Conejin_Alt’s method of LOD is pretty simple, just have checks when a player is in a certain chunk, then “load” chunks by making them appear via transparency from 0 to 1(though if there are parts with different transparencies, you’ll have to store a table of some sort to keep track of the transparency and set them as usual). Although this is simple, it does put much less strain on the server rather then having all appear however, collisions would still stay meaning it still is there/other things. You decision on what to choose though 
, having collision stay might even be good from some things.
@MrLonely1221’s method does somewhat work however, moving parts/objects continuously in my opinion would give lag spikes every once in a while if you travel fast in chunks/etc. Moving them far away isn’t a good idea either though. (I might be reading it wrong so don’t mind me 
)
Another method would be to parent and unparent them when getting in a certain chunk. Kinda confusing but let me explain:
Let’s say you had map1, map2, and map3. Map1 is close to map2 and map 3 is close to map 2 but not 1 and vice versa. If a player is in map1, map2 would load a little/all but map3 won’t load at all/won’t be parented to workspace.
This in turn makes sure that even if the player travels fast, the area would stay loaded just in case as to allow the player not to fall to the abyss/get confused. (Side note, you can parent models/objects in and out of workspace via changing the parent to nil/to workspace, just make sure you keep it in check and remove as necessary to prevent memory leaks, might be possible though Idk)
However, depending on the map like @MrLonely1221’s method, this could cause some sudden lagspikes when loading in maps per usual, especially if you can travel back and forth like if you were to be in map2 yet you could go between map1/map3. However, this will help with performance/ “reduce” part count and lag.
Now then, to move to your method. It works similar to bloxburg’s method of LOD very much where they load/unload parts inside buildings as to reduce lag and load in when they get near. I don’t know if its better to keep it in Replicated Storage and move it in and out though It should work the same as parenting nil/etc so I don’t find anything bad, I might be wrong though.
I wouldn’t think of it to be necessary to make low very LODs of each map however, you can just “tag” parts via CollectionService/etc on parts you want to be gone during the LOD process without duplicating/making more parts/increasing part count.
Depending on your map, chunking/other things would work better. Let me explain again, if your game works like Speed Run 4, where maps are separated from one another, having a “chunk” of the entire map would be a good idea. If it’s like Minecraft, having chunkify the map in squares would be a better idea rather then regions though personal preference.
One last thing, looking at other people’s methods of LOD helps quite alot, one of the methods I explained above can be seen here: Chunk Loading System - Roblox (Credit to TheNexsusAvenger, some parts however might be outdated/some functions deprecated though It’s still useful)
Another good example by dogwarrior24: Infinite Terrain - Roblox
Original post by dogwarrior24 if you’re more interested: [Open Source] Infinite Terrain & Level of Detail system
Hopefully this helps, good luck 
