Establish where fixed-asset and maintenance capability actually lives in the source estate before designing anything, and rebuild an asset register that reconciles asset by asset at cutover.
This is the thinnest-evidence domain on this path, and pretending otherwise would be worse than saying so.
Start from the accounting, not from the system. The depreciation charge appears in the ledger every month, and somebody produces it. That person knows where the register lives.
In D365, depreciation behaviour is expressed through Books attached to a fixed asset. Each Book carries its own depreciation profile, convention, service life and posting behaviour, so one asset can be depreciated several ways for several purposes simultaneously.
Method names transfer badly. Two systems can both call something straight-line and produce different monthly charges because of conventions the name does not carry:
The rule is the same as for inventory, and for the same reason: load the position, do not replay the history.
Beyond the register itself, the target links assets to procurement more formally than mid-market source practice usually does. A purchase can create or update an asset directly, with the acquisition posting flowing through the asset posting design.
Asset management in D365 covers maintenance assets, maintenance plans, work orders and their cost linkage. Whether any of it belongs in scope depends entirely on what the client does today.
Supported: the target's fixed-asset and Book model; the wave in which assets load; the asset-by-asset reconciliation gate; the requirement to inventory add-ons with vendor, version, licence and data ownership; and the general warning that client-specific behaviour varies by localisation, patch level and ISV stack.
Assets are a discovery-and-reconciliation domain on this path, not a mapping domain.