In About MOF Files Used by Hardware Inventory, the behaviors of the Configuration.mof and SMS_def.mof Configuration Manager 2007 hardware inventory files are described. While that topic does say that the Configuration.mof is used for data classes, and the SMS_def.mof is used for reporting classes, some additional detail about how this affects you when you upgrade from SMS 2003 (and need to migrate existing hardware inventory customizations) could help out here.
(Before you ask, yes I'm going to update the docs with this information, but I won't be able to do that for a while so I'm posting this information here for now.)
If you've made hardware inventory modifications in SMS 2003 that you need to migrate--either in the SMS_def.mof or a "mini-mof" you'll need to separate the data classes from the reporting classes before adding them back in after the site upgrade has completed successfully. Before beginning the upgrade process, copy your SMS_def.mof or mini-mof to a new location so you can re-create the modifications after upgrading the site.
After upgrading the site, open up your mof file backup and copy the data class information to the bottom of the Configuration.mof (the Configuration.mof is located in the same directory as the SMS_def.mof file--.\inboxes\clifiles.src\hinv). Data classes contain the location and properties of the information stored on client computers that you want to inventory and are usually located in the root\cimv2, or some other, WMI namespace.
Next, copy the reporting class information into the bottom of the new SMS_def.mof created during the site upgrade process (reporting classes are always located in the root\cimv2\sms namespace).
Tip: When looking through the SMS_def.mof or mini-mof, you can see where WMI namespace changes are made by looking for lines like #pragma namespace root\cimv2 (data classes) or #pragma namespace root\cimv2\sms (reporting classes). Everything listed after a #pragma namespace line exists in the namespace designated in the change line.
If you're currently using a mini-mof with SMS 2003, then you're also probably using a #pragma include command to append the mini-mof data to the SMS_def.mof and client inventory policy created by the contents of the SMS_def.mof file. This works fine because the SMS_def.mof file is not actually sent to clients to compile, rather the contents of the SMS_def.mof file are turned into a policy compiled by clients. #pragma include commands are WMI commands and are recognized by the MOF file format and MOFCOMP.EXE--so it's not a function of SMS that allows you to use this command to append the contents of the mini-mof to the SMS_def.mof.
In Configuration Manager 2007, the Configuration.mof file itself is actually sent to clients as part of the client inventory policy body downloaded and compiled by clients. This means that any data that you need clients to compile must be defined in that file--so you can't use the #pragma include command to append a mini-mof file physically to the Configuration.mof. You can try, and data loader won't even blink because #pragma include commands are valid WMI commands and MOFCOMP.EXE will happily compile the updated file with no errors--the include command will just mean nothing to Configuration.mof behavior and will result in an invalid policy when clients evaluate it. In other words...you can do it, but it just won't work. If this happens, you'll need to dig through some policyagent.log files on clients to discover what happened and then go fix the Configuration.mof to get clients to perform proper hardware inventories with an updated, valid policy.
However, #pragma include still works in the Configuration Manager 2007 SMS_def.mof, because that functionality hasn't changed in Configuration Manager--the contents of the SMS_def.mof (whether physically in the file or logically appended to it using a mini-mof) are translated into an inventory policy automatically compiled by clients. This is a handy bit of information because now you know how to test hardware inventory modifications without adding them to the Configuration.mof and affecting all of your production clients. Just add the reporting classes to either the SMS_def.mof or append them via a mini-mof and then manually compile a data class .mof on a few test clients to see how things go (unless they're in the Configuration.mof, the custom data classes would still need to be manually compiled on clients just like SMS 2003 behavior).
With all that being said, I wouldn't personally use mini-mof files anymore in Configuration Manager. They don't work for the Configuration.mof and could lead to confusion later on in the SMS_def.mof. My recommendation here is to just add in customizations physically into the Configuration.mof or SMS_def.mof for Configuration Manager sites.