How to export modules

I installed suitecrm 7.14.2 on a new machine, now I would like to export my custom modules from an old machine on which suitecrm 7.12.14 is installed, what is the correct procedure?

I went to Studio and clicked on “export customizations”, I selected all the indicated modules and created the .zip file.

Then I went to module loader and installed the package, but nothing happens, everything was fine, no errors, but the modules were not installed, not even after a quick repair.

The module tables are not present in the DB, but only the connection tables between the customized modules (modules A and B are not present, but table A_B_1_c is present).

Where am I wrong? Is the procedure I followed correct? Thank you.

Can anyone give me an answer? Please

I would first try to simply copy the files, not export/import.

The files are in custom directory, of course, and also sometimes in modules/mymodule

After copying, run a QR&R and see if there are any queries at the bottom of the screen, click to execute them.

in a first approach I had tried to copy the files directly, but there are too many dependencies, not only the modules, but also what is found in the extension folder and probably in other folders. the result was a general malfunction in several modules, not only errors that I gradually resolved (long process), but even without explicit errors, the modules did not work as they should have.
for this reason, having seen the possibility of exporting custom modules directly, I thought that this solved all the dependencies, but it didn’t import anything and I don’t understand why.

Why don’t you simply upgrade first, then migrate without any changes?

because, as said above, I’m installing the system on a new machine where I don’t have suite, I took the latest version (before 8) directly from the suitecrm site and then I thought I’d pass on the custom modules.
I don’t understand, there is the possibility to “export custom modules”, but it doesn’t work? Is the error mine or the system’s? Is the procedure correct?

I would not be surprised if the export modules function did not work, or if it had limitations that we are not aware of. As you experienced yourself, moving modules can get quite complex, and I just don’t see how that old code can manage it. I don’t think it is often used.

Most people prefer the method of moving files, using source control, etc. Of course, you need to have some notion of what is going on, to solve any problems that arise.

But I really think you should avoid the strategy you’re currently taking. You’re doing what I call a migrate-and-upgrade, which is never a good idea. Your trying to migrate into a different (upgraded version).

Each of the two processes can be complex, so you must try them each on their own, making sure you have a valid system in between the two steps.

So, either…

  • install your new system with 7.12.14, migrate the files, validate, then upgrade


  • back up your old system, then upgrade it to 7.14.12, validate, then migrate to new server

ok, then I’ll try to go back, delete version 7.14.2, install 7.12.14 and try to import the custom modules here, with the procedure described before (I don’t think it works like that either, but I’ll try) and then I’ll do the system upgrade.
two things to ask:

  1. do you know where to find version 7.12.14? on the site I only find upgrade files, but I can’t find an installable version of this version only

  2. I have a doubt, the “export customizable modules” procedure, is it possible that it needs to be performed after exporting the modules? Meaning what:

A. go to “form builder” select my form, export it and then import it into the new system
B. go to Studio, click on export custom modules and import them into the new system.

Is it possible that this is the procedure to adopt?

Every version and upgrade is stored here:

I can’t vouch for the export/import procedures. I would never use them myself, because I don’t expect them to bring me less trouble than a simple file copy followed by a QR&R. And on the downside, I wouldn’t know exactly what it did, and what it didn’t do.

Also, not that by separating migration from upgrade, you really shoulnd’t have to worry about modules or customizations. The migration won’t break that because you will be moving the entire SuiteCRM directory and the entire database. The upgrade won’t break them because it’s just an upgrade like so many others you’ve done in the past.

That approach is not the best engineering approach and will take up a lot of time for little value - it’s best practise to run some Virtual machine technology on your PC so that you can ran 2 or more different versions as the same time: each with their own code base+database.

They also allow you to create ‘instant snapshots’ - which you can roll back to very easily: which again makes trouble-shooting and experimenting easier.

People use docker or VMWare type tools for that.

I wanted to install version 7.12.14 and then pass the custom modules, but it’s not possible because this version only supports PHP up to 8 and PHP 8.2 is installed on my machine.
So I installed the latest version of Suite 7 (7.14.2) after which I followed the procedure described above:
as I thought, you must first export the created modules via module builder, and then import them into the new system; then you have to go to Studio and use “export custom modules” and install these on the new system too.
in this way we will also have the creation of the my_module_cstm tables.
the problem is that extension relations and layoutdefs are not exported, so I will have to manually create the relations and copy the layoutdefs files into the respective folders, unless there is a way to make these procedures automatic.

I have notes on how to migrate from 7 > 8 while retaining all custom fields in studio etc - I’ll dig them up for you and make them legible - there’s a couple of database tables dependant.

You are correct, into studio and export the module on old suite - Then import the module into the new suite

copy over the DB table fields_meta_data and you should be golden to import your records - suite will then put them in.

You’ll then have to export the specific tables that contain your data relationship links - f.ex contacts and cases

You import contacts first, then import cases - do this through the front end!! not the database.

You open a contact and there’s no case there.

Export the db table - contacts_cases and import to your new suite database - this then puts the relationships back.


Same principle for the other modules, accounts and contacts, there’s an accounts_contacts table, etc etc etc

From memory this should give you a headstart - I’m available on discord if you need a 1-1 helper :slight_smile: just send me a PM :slight_smile:

Hey @ fab, Custom Modules and Module Builder export is not very well documented. I’ve spent a lot of time figuring out the minute details. Here’s a quick summary of how it works:

The Export and Publish options in Module Builder both create a zip file containing the custom module package which can be migrated to another instance.

The Publish option will have the custom module show up in Studio once it is installed. The Export option will have the custom module appear in Module Builder, which will need to be deployed in the instance once it is ready for use.

So, if the module was “Published” and then installed, it will not have the related module builder stuff to be able to export. Also, even if you do have the module builder stuff to export, it’s not current. It’s the original export and does not include any customizations that may have been done in studio. In which case it’s still possible to export, you’d have to do in two steps, first either export or publish the module, then export the customizations from studio.

As mentioned if it was originally installed as “Publish” you wont have the module builder files to export.

Theoretically, you can just copy over the main folder in the core for custom modules and the “custom” folder for the custom module and then run a quick repair and rebuild and everything should be there. (other than the data).

(I’m talking 7, I’ve never done this process in 8 yet)

Hi @dhuntress and @pstevens
so it’s not possible to export all customizations, right? From what I was able to understand.
I exported the modules and then imported them, I then exported the customizations and then imported them, now I have the MY_MODULE and MY_MODULE_cstm tables, from what I understand, to also have the relationships I have to export the tables from the DB (but at this point it is preferable to create them again in Studio), in the same way I don’t have the customizations that I developed in Extension/layout or Extension/vardefs… can you confirm that this is the case or have I misunderstood?

Why are we complicating this so much?

What exactly are the downsides of a full copy from the file-system?

  • Copy the custom dir, and any custom modules under modules dir.
  • Do it between systems at exactly the same version. I know, people want to skip this clause, but really, don’t; just leave upgrading for a moment when you’re not migrating, they’re two separate things
  • copy the full DB
  • Enjoy

Works great with source control.

Hey @pgr, 100% agree, that’s what I’d do, copy over everything exactly, including the DB and upgrade in place. However, I think he mentioned in the threads above he only wants “some” of the custom modules to come over to the new installation.

Personally, I’d still move everything over, upgrade in place then delete the unwanted modules.

@pgr as already explained above, I cannot install the same version (7.12.14) on my new machine, because I installed PHP 8.1 and this version of suitecrm supports PHP up to 8.0, so I had to install suite 7.14.2 and therefore I cannot do copying the custom directories and pasting them into the new system, also because I have already done a similar test and there were some modules that did not work as expected, if it were enough to copy and paste the files contained in the Custom/Modules and Extension/Modules directories I would, but evidently suite also creates other dependencies in other directories.

This is not really a strong reason, you can install more than one version of PHP and swithc between them as needed. Much less work, IMHO

These problems are the ones that would be worth figuring out; and no, I don’t think there are other dependencies apart from the one I listed (which are not quite the same that you listed in your reply).

I’m not trying to be a prick, don’t get my tone wrong. I’m just trying to keep things clear in my head. I’m glad you have things working :+1:

Hi @fab - I already posted above about Docker and VMware - using a virtualisation/container type tool (there are others) - worth learning - it will save you a lot of time over your future coding career.