Hello, I’m trying to upgrade our unmanaged SuiteBu...
# suite-app
i
Hello, I’m trying to upgrade our unmanaged SuiteBundler SuiteApp to an SDF SuiteApp. My goal is to upgrade users to the new SDF Suiteapp. When installing the SDF SuiteApp, it treats it as a new app install and then it complains that the custom record types already exist - which is true because the SuiteBundler app is still installed. How can I configure the SDF suiteapp to adopt the existing custom records without having to create new custom records and do a data migration? I’ve also tried listing the suitebundler as a dependency…which kind of works but now customers can’t install the SDF suiteapp without the suitebundler app which we plan to EOL
r
From what I know you need to rename the records so they don’t match and also do a data migration.
t
I think this is probably related to App ids
you needed to use an App id when creating your suiteapp. You'll need to assign that app id onto all existing custom objects
i
thanks for the responses @Ryan Longenecker do you know what the best recommended way of doing data migration? installation scripts seem to have a processing limit of 10000 units and I believe there could be customers that could reach that limit
@The Usual Suspect how do we assign that app id onto existing custom objects?
t
When you install an object from a suiteapp via SDF it automatically adds it
If you don't you need to....manually add it after the fact
Enable the setting above then navigate to a custom object and you'll see it near where the other ids are
Not sure if you can automate the task so if this is the issue and you have a lot of objects you might need to flag down the intern
r
I have seen tools that look at the old bundle installed and the new suiteapp and are able to move each file over. Then they can uninstall the bundle. Guessing it’s saved searches to pull the old records, script to update to the new IDs needed or record types but don’t know much more.
i
@The Usual Suspect i just tried that and it works. One caveat though is that since that custom object type is still owned by the bundle, a customer could inadvertently uninstall the bundle and also remove it. We could instruct customers to remove all script deployments of the bundle and keep the bundle installed indefinitely
🙌 1
t
You used to be able to add app ids onto bundles as well
you maybe still can?
not sure if that will fix or help here at all
i
not sure either. but this seems like an alternative solution without needing to do data migration
👍 1
creating new records for the SDF suiteapp could be cleaner, but then I’d have to do data migration. data migration seems tricky since suitescript governance gives only 10k usage units for the sdf installation script which can easily be reached. I’d have to do periodic migration job or do it lazily as records are being accessed
t
one quick thing. You should ensure that data migration is still not needed. I haven't done tests myself on overwriting bundle objects with sdf / suiteapp installs. You may want to test this on something small scale and even create a test bundle / app to ensure there is no data loss
i
ah, one thing i forgot to mention is that i also had to change the custom record ID in addition to the app id. first of all, netsuite doesn’t seem to allow sdf installs to overwrite the bundle’s custom object types….it won’t even let you install if you have the same custom object definitions defined. the solution seems to force me to rename all custom records for the SDF app and then you can rename the app id and the custom record id of bundle’s custom object to match the ids in the SDF app.
👍 1
there won’t be data loss it seems, but i think switching just the app id is not sufficient
t
Well it seems like NetSuite is going to make this a massive pain in the ass but at least you know more than you did before?
Sorry I can't help out more. I wish I had a silver bullet
i
no problem! i don’t think NS is gonna make it easy either. but that’s fine. this was helpful though
👍 1
s
The other pain point here is if you have custom transaction fields that are populated with data in closed periods.