The upside of not having access to the data is that it offers you a level of security. Also, the IFS team has their heart in the right place, and really works to make things right. The difficulty, at times, is that they may face a resource constraint.
Once we got comfortable that we didn’t need the security of no access as well as having the need for multiple changes, we moved away from IFS hosting. While we like the IFS team, having others host, and consult, seems to be the better option for us.
There are only three choices really:
- Pay IFS to package and deliver
- Pay an IFS Partner to package and deliver
- Maintain an IFS Developer on staff that can package and deploy the configuration changes directly (this is our mode of operation)
If you are making changes often (more than once a month), I’m sure you’ll find significant value in having a developer on staff for all sorts of issues, development, and deployment.
Hi CJ,
I know that we discussed access limitations during the sales cycle, as this was something that was going to be an adjustment for the SPX Team, coming from an on-premise deployment. You mentioned that a number of your “changes” require a delivery however, most changes would be executed in the Configuration Layer within the User Interface which you can move across environments yourselves, without a delivery.
We will reach out to you offline so that we can further discuss and determine if we have a misalignment or opportunity for further clarification.
Thanks!
Amy
