Martina is giving the very short answer, but you may first need to learn two things:
1. Forms (SCX) and also classlibs (VCX) are actually DBFs and organize their structure in records for objects (controls), code and parent relationships to what contains them.
2. These errors only happen when you start a form or instantiate a class that still has what you tell is replaced in your application: an OLE control, well, any class, not only ActiveX, which VFP searches in the registry, so that would also apply to COM automation servers, but they would usually be instantiated by code and not give such a record number related error message. A line of oExcel=CreateObject("Excel.Application") causes a "class not registered" error in the normal way, for a method or program and line number. The way a record-number related error message is caused is when a form or class is constructed from the data in the SCX or VCX. And as that also happens without code in init, too, it's not related to code, also not Load event code, it's related to the construction mechanism of forms and classes driven by data about their composition.
It could be something you still use and consider available without (co-)installation, like the Common Controls or an Excel Spreadsheet. The former isn't as common since several Windows versions, you're having the license to deploy them with your setup, but they don't get there automatically and are not part of the core VFFP runtime. And the latter (an Excel Spreadsheet or any such Office specific visual class) won't work if Office isn't installed or if the control on the form specified a version number not installed. I would also say an Olebound control can cause that, though it's a native VFP control. But its main intent is to combine an OLE server with data or a concrete OLE instance, and one part is usually general field and then an OLE control that is using this general field, i.e. it would contain the cell content of an Excel spreadsheet object, but not be the Excel spreadsheet itself, it still needs Office Excel to become an actual Excel Spreadsheet.
So there are things you could have overlooked. Besides even just the usual Ole control you already focused on replacing. It's not hard to overlook something.
Which loops back to perhaps not knowing SCXes and VCXes are DBF tables: Because if you knew that, it would be easy to ensure you have worked on every form or class that uses OLE, if you looked for content in the OLE2 fields of all SCX and VCX and FRX and LBX files in your project.
Chriss